In my main laptop, various power supply problems arise frequently, which can be explained by working on insider builds. However, even in the stable version 1803, I noticed that my system stopped going to sleep. In this case, the monitor turned off after a specified period of time, which hinted at the system correctly determining the state of inactivity.
I set a short period of transition to sleep, 1-2 minutes, and began diagnostics.
Checking requests to the power subsystem from applications and drivers
The first thing you need to do is look at powercfg, which keeps the OS from going to sleep. Processes and drivers accessing the power subsystem can be seen in command line as administrator:
Powercfg-requests
It is immediately clear that the request to SYSTEM comes from DRIVER - in this case, Realtek uses an audio stream.
WebRTC from Chrome may also be present in the list, and immediately after the system is restarted, you can see download optimization requests and a search index, but they quickly disappear. You can add a process or driver to the exception list, and it will not prevent it from going to sleep.
Powercfg -requestsoverride DRIVER "Realtek High Definition Audio (HDAUDIO\FUNC_01&VEN_10EC&DEV_0269&SUBSYS_17AA2204&REV_1002\4&d00657&0&0001)" SYSTEM
The command reads "ignore request from DRIVER [full driver name] to SYSTEM."
The list of exceptions is stored in the registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerRequestOverride
and is output by the command
Powercfg -requestsoverride
I rebooted to be sure, but the system refused to go to sleep. After checking the exceptions and the query list, I found that Realtek driver continued to use the audio stream, although it was included in the exceptions.
I danced a little around exceptions, but was not successful. A quick Google confirmed that in some cases they don't work. This is typical for legacy requests, but there was another case, and I’m not the first to encounter this.
I ended up removing Realtek from the list. You can delete entries in the Registry Editor or Console. The command is almost the same as when adding, it just doesn’t indicate where the request goes, i.e. in this case there is no SYSTEM at the end of the command:
Powercfg -requestsoverride DRIVER "Realtek High Definition Audio (HDAUDIO\FUNC_01&VEN_10EC&DEV_0269&SUBSYS_17AA2204&REV_1002\4&d00657&0&0001)"
We'll go a different way
Compute a process that uses the audio subsystem
It is known that the Realtek driver does the dirty work. Obviously, it is loaded at system startup, so the file name is easy to find out using Autoruns.
Three entries refer to two files, one of which is a control panel, judging by the name. Therefore, the object of interest became ravbg64.exe.
Kernel Mode Drivers: Part 1: Basic Concepts - Archive WASM.RU
Architecture overview
The inner world of Windows 2000 is divided into two parts with clearly defined boundaries, both in terms of address space and in terms of the rights and responsibilities of the code running in that address space.
With address space division, everything is surprisingly simple. All four, available in 32 bit architecture, gigabytes are divided into two equal parts (I omit 4GT RAM Tuning and Physical Address Extension as exotic). The bottom half is given to processes user mode, the top one belongs to the core.
The division of rights and responsibilities is a little more complicated.
The following processes are considered user processes:
- System Support Processes - for example, the Winlogon logon process (implemented in \%SystemRoot%\System32\Winlogon.exe);
- Service Processes - for example, a print spooler;
- User Applications - There are five types: Win32, Windows 3.1, MS-DOS, POSIX and OS/2;
- Environment Subsystems - three environment subsystems are supported: Win32 (implemented in \%SystemRoot%\System32\Csrss.exe), POSIX (implemented in \%SystemRoot%\System32\Psxss.exe), OS/2 (implemented in \%SystemRoot%\System32\os2ss.exe).
The core consists of the following components:
Executive system - memory management, processes and threads, etc.;
- Kernel - scheduling threads, dispatching interruptions and exceptions, etc. (implemented in \%SystemRoot%\System32\Ntoskrnl.exe);
- Device Drivers - hardware device drivers, network drivers, file system drivers;
- Hardware Abstraction Layer (HAL) - isolates the above three components from differences between hardware architectures (implemented in \%SystemRoot%\System32\Hal.dll);
- Windowing And Graphics System - Graphic User Interface (GUI) functions (implemented in \%SystemRoot%\System32\Win32k.sys).
Rice. 1-1. Simplified diagram of the Windows 2000 architecture
User mode and kernel mode
Although the Intel x86 family of processors support four levels of privilege (called rings of protection), Windows uses only two: 0 for kernel mode and 3 for user mode. This is due to the support of other processors (alpha, mips), in which only two levels of privileges are implemented. Previous releases of Windows NT supported these architectures, but Windows 2000 remained x86-only.
User mode components have their own protected address spaces, the threads of these processes run in unprivileged processor mode (called user mode), cannot execute privileged processor commands, have limited and indirect access to system data and the system address space, and do not have direct access to hardware . True, during their work, the threads of these processes, calling system services, switch to kernel mode, but in this case they completely lose control over their execution until returning back to user mode.
User mode processes are considered potentially dangerous from a system stability point of view. Their rights are limited. And any attempts to go beyond these restrictions are harshly suppressed.
Kernel components share a single address space, execute in privileged processor mode (called kernel mode), can execute all processor instructions, including privileged ones, have unrestricted and direct access to system data and code, and have direct, or via HAL, access to the equipment.
The kernel code (in fact, this is the system itself) is considered completely trusted. Therefore, once loaded into the system address space, the driver becomes part of the system and is not subject to any restrictions.
Thus custom applications separated from the operating system itself. If you set out to write any serious application that requires access to internal functions or data structures of the system, you will encounter many limitations that can only be overcome by placing your code in the system address space. There is only one documented way to do this - install the device driver. This method is relatively simple, reliable, and most importantly, fully supported by the operating system itself.
Windows 2000 Drivers
Windows 2000 supports many types of device drivers.
There are two basic ones that have their representatives:
- User-Mode Drivers:
- Virtual Device Drivers (VDD) - used to support MS-DOS programs (not to be confused with VxD drivers in Windows 95/98 - these are completely different things, although they have the same name);
- Printer Drivers.
- Kernel-Mode Drivers:
- Drivers file system (File System Drivers) - implement I/O to local and network drives;
- Legacy Drivers - written for previous versions Windows NT;
- Video adapter drivers (Video Drivers) - implement graphics operations;
- Streaming Drivers - implement video and audio input/output;
- WDM drivers (Windows Driver Model, WDM) - support Plug and Play technology and power management. Their distinctive feature is compatibility at the level source code between Windows 98, Windows ME and Windows 2000.
In different sources you may come across a classification slightly different from the one given above, this is not important. The important thing is that the drivers that we will write do not fall under any of the points in this classification. These are neither file system drivers nor legacy drivers nor video adapter drivers or sound cards, nor WDM drivers, because do not support Plag"n"Play and power management. These are not user mode drivers (that's not interesting at all). In fact, it's just the devil knows what it is, because... the system itself allows you to easily and simply add code to itself for an unknown device, and do whatever you want with it! It’s as if a complete stranger knocked on your door at night, and without saying a word you let him in for the night, and even put him in your bed! However, this is not some kind of bug or security hole. The system just works the way it does. It cannot be otherwise, because... interacting with the environment, the system is forced to provide access to itself. And if this were not so, then it would be a completely closed, and therefore useless, system.
As the name itself suggests, a device driver is a program designed to control some device, and this device does not necessarily have to be physical. It can be logical or, as in our case, virtual.
In its structure, a device driver is nothing more than a PE-format file (Portable Executable, PE). Same as regular exe and dll. It just loads and works according to different rules. Drivers can be thought of as kernel-mode DLLs designed to perform tasks that cannot be performed in user mode. The fundamental difference here (not counting the level of privileges) is that we will not be able to directly access the driver, neither its code nor its data, but will use a special mechanism provided by the Input/Output Manager. The I/O manager provides the environment for drivers to function and also provides mechanisms for loading, unloading, and managing them.
When you start developing kernel mode drivers, you will feel like a complete beginner because... all previous experience API usage won't help here - the kernel provides a completely different set of functions. You will also have to use poorly documented (defined only in header files) or completely undocumented functions and data structures.
Single and multi-level drivers
Most drivers that control physical devices are layered drivers. Processing of an I/O request is shared among multiple drivers. Everyone does their part of the job. For example, a request to read a file is sent to the file system driver, which, after performing some operations (for example, splitting the request into several parts), passes it “downstream” to the disk driver, which, in turn, sends the request to the bus driver. In addition, between these drivers you can add any number of filter drivers (for example, data encryption). Having executed a request, the lower-level driver passes its results “up” to the higher-level driver. But, fortunately, everything will be much simpler for us. Our drivers will always be monolithic drivers, which will greatly simplify the entire process of writing and debugging them.
Thread context
Since, in most cases, we have only one processor, and there are many applications that need to be executed, it is natural that in order to create the illusion of their simultaneous execution, these applications must be connected sequentially to the processor, and very quickly. This procedure is called thread context switching. If the system switches the context of threads belonging to the same process, then it is necessary to save the value of the processor registers of the disconnected thread, and load the previously saved values of the processor registers of the connected thread. And update some data structures. If the connected thread belongs to another process, then it is necessary to load the pointer to the page directory of the process into the processor's CR3 register. Since each user process is provided with a closed address space, different processes have different projections of address spaces, and therefore different page directories and sets of page tables through which the processor translates virtual addresses into physical ones. All this is not directly related to driver programming. But I remind you of this in connection with this. Since context switching is not the fastest operation, drivers, for reasons better performance, as a rule, do not create their own threads. But the driver code still needs to be executed. Therefore, to save time on context switching, drivers run in kernel mode in one of three contexts:
- in the context of the user thread that initiated the I/O request;
- in the context of a kernel mode system thread (these threads belong to the System process);
- as a result of an interruption (and therefore not in the context of any process or thread that was running at the time of the interruption).
I don’t quite understand how you can do something “not in the context of any process or thread,” but given the authority of the people who wrote this (D. Solomon and M. Russinovich), and also the fact that we don’t need this, because . We will not process either software or, especially, hardware interrupts; you can immediately forget about the third case. The first two options remain. If an I/O request is initiated, then we are in the context of the thread that initiated this request, and therefore we can directly access the address space of the process to which this thread belongs. If we are in the context of a system thread, then we cannot directly access any user process, but we can always access a system one. If you need to see from the driver what some process has at such and such an address, you will either have to switch the context yourself or translate the addresses using page tables.
Interrupt request levels
Interruption is an integral part of any operating system. An interrupt requires processing, so execution of the current code stops and control is transferred to the interrupt handler. There are both hardware and software interrupts. Interrupts are serviced according to their priority. Windows 2000 uses an interrupt priority scheme known as interrupt request levels (IRQL). There are 32 levels in total, from 0 (passive), which has the lowest priority, to 31 (high), which has the highest priority. Moreover, interrupts from IRQL=0 (passive) to IRQL=2 (DPC\dispatch) are software, and interrupts from IRQL=3 (device 1) to IRQL=31 (high) are hardware. Don't confuse interrupt priority levels with thread priority levels - they are completely different things. An interrupt with level IRQL=0, strictly speaking, is not an interrupt, because it cannot interrupt the work of any code (after all, to do this, this code must be executed at an even lower interrupt level, but there is no such level). User mode threads execute on this IRQL. And our driver code will also run on this IRQL. This does not mean that any driver code is always executed at the "passive" level. It’s just that we won’t handle either software or, especially, hardware interrupts. And from this follow at least two very important conclusions.
First: the work of our drivers can be interrupted at any time to process an interrupt with a higher priority (for example, from a timer, when the scheduler considers that our thread has already had the processor for long enough and it’s time for it to rest). Therefore, in this sense, the code of our drivers is interruptible and preemptible (the processor is given to another thread), just like the code of any user thread. There are kernel functions that allow you to find out the current interrupt level, as well as raise or lower it.
Second important point: at the passive interrupt level, you can call any kernel functions (in the DDK, the description of each function must indicate at what interrupt level it can be called), as well as access memory pages flushed to the swap file. For more high levels interrupts (DPC/dispath and higher), an attempt to access a page that is not in physical memory leads to a system crash, because The Memory Manager cannot handle a page fault.
"Blue Screen of Death"
I think everyone, at least once, has seen a disturbing picture called “blue screen of death” ( Blue Screen Of Death, BSOD). There is probably no need to explain what it is and why it occurs. The important thing here is that when you start developing kernel mode drivers, get ready for the fact that BSOD will appear on your monitor screen quite often.
In the third ring, everything was simple: I sketched out the approximate code, placed int3 where necessary, launched it and... in the debugger you already understand what's what. If something is wrong, I fixed it, corrected errors, recompiled... and so on until the code works as it should. When programming drivers, you can forget about this technique. Here the "sapper" makes a mistake once. One wrong move... and you can sit back and relax for a minute.
In order to see BSOD as rarely as possible, you should adhere to one very simple rule: “Measure seven times - cut once”... in the sense of “Check seven times - run once”. This is of course easy to say, but much more difficult to do. But as a rule, given that the structure of the drivers that you will write (after reading these articles) is relatively simple, you can deal with errors before the BSOD appears. If it persistently appears before your eyes, and you cannot understand the reason, possible way To clarify the situation is to analyze the crash dump. You can read about what it is, how to make it and analyze it in the article by Mark Russinovich “Analysis of crash memory dumps” http://www.osp.ru/win2000/2001/03/025.htm. This matter (analysis) is very difficult, but I think it won’t come to that.
I'm a terrible theorist, so you can consider all of the above as very basic information about the principles that are absolutely necessary to understand. You can't start developing kernel mode drivers without understanding what a thread context is, interrupt levels and thread priorities, kernel/user mode, etc. and so on. If you feel unsure about some issue - the list of references is below.
Now let's cover some more practical things (they will become very practical in the following articles), namely, what we need to turn all this theory into practice.
Driver Development Kit
The first is, of course, the Device Driver Development Kit (Windows 2000 Driver Development Kit, 2KDDK), which can be freely downloaded from the Microsoft website (in any case, I downloaded it completely free of charge from here: http://www.microsoft.com/ddk/). This package includes documentation that is a rich source of information about internal structures data and internal system functions used by device drivers.
In addition to documentation, the DDK includes a set of library files (*.lib) that will be absolutely necessary when linking. The DDK includes two sets of these files: for the final Windows versions(called free build); and for development (called checked build). These files are located in the %ddk%\libfre\i386 and %ddk%\libchk\i386 directories, respectively. The debug version has more stringent error checking. You need to use files corresponding to your system version by placing them in the \masm32\lib\w2k directory.
Included files
We will also need include (*.inc) files with function prototype definitions. We (more precisely, I) will also have to do them ourselves. I tried many different utilities that convert *.lib -> *.inc, both included in the masm32 by hutch package, and those I leaked at different times from the vast expanses of the Internet. Of all the ones I have, only protoize.exe by f0dder coped with its task, and I practically didn’t have to edit anything by hand. This wonderful tool will be located in the \tools\protoize directory. Author's website: http://f0dder.didjitalyphrozen.com/. But you won't find it there. f0dder posted this utility several times in the http://board.win32asmcommunity.net/ conference. Includes will be located in the \include\w2k directory. They should be placed in the \masm32\include\w2k directory. For conversion, we used *.lib for the free release of Windows 2000, since this is the version I have (and you, probably, too).
The next problem is more serious. This is an almost complete absence of include files with definitions of the necessary structures, symbolic constants and macros. You are unlikely to be able to find anything useful on the Internet - this is too exotic an activity - writing kernel mode drivers in assembler. Some can be found at EliCZ http://www.anticracking.sk/EliCZ/. Something from Y0da http://mitglied.lycos.de/yoda2k/index.htm (partially made by him, partially taken from the same EliCZ). But this was done extremely poorly (with all my deep respect for our Slovak and German colleagues): the names of the members of many structures differ from those defined in the original header files from the DDK; nested structures and unions do not have names; although in the original they are named. And in general, everything is in some disarray, and when viewed it gives a depressing impression. Only ntstatus.inc is well done. This is partly due to the fact that EliCZ began creating his inclusions even without DDK (as he himself says). In any case, I do not advise you to use them, at least without careful testing. Something, at one time, flashed in the conference http://board.win32asmcommunity.net/, but the quality is also not particularly impressive. In short, the only correct solution in this situation, do everything yourself, and manually, because I am not aware of any tools that allow you to automate this process. If you suddenly come across something worthwhile and don’t think it’s too much trouble, let me know.
Debugging drivers
We also need a debugger, and since we will have to debug kernel mode code, we need an appropriate debugger. The most best choice will be SoftICE. Or you can use the Kernel Debugger included in the DDK. This debugger requires two computers - a master and a slave, which not everyone can afford. Mark Russinovich (http://www.sysinternals.com/) wrote a utility called LiveKd, which allows you to use Kernel Debugger without connecting a second computer. I don’t know if it’s on the website (I haven’t checked), but it’s on the CD for the book." Internal organization Microsoft Windows 2000" is available. This debugger is also extremely useful for examining the internal structure of the system, provided that you have debugging symbols installed, which can (or could be) freely downloaded from the Microsoft website.
David Solomon, Mark Russinovich, "The Internals of Microsoft Windows 2000", ed. "Peter", 2001. Although this book does not contain a single line of source code, it is primarily for programmers.
Sven Schreiber, "Undocumented" Windows features 2000", publishing house "Peter", 2002. A purely practical book that reveals many of the secrets of Windows 2000.
Walter Oney, "Programming the Microsoft Driver Model", Microsoft Press, 1999 In this book, the emphasis is on Plag"n"Play drivers, but this in no way diminishes its merits, because The basic principles of driver development are universal.
Jeffrey Richter, "Windows for Professionals: Building Powerful Win32 Applications with the Specifics of 64-Bit Windows," ed. "Peter", 2000. This book has nothing directly to do with driver programming, but it is also very interesting ;-)
This list is by no means intended to be complete. Much, especially in English, can be found on the Internet (except for Schreiber, all books are available in electronic form). Regarding books, I would also like to say that they are all “must have”. You see - buy without looking. All except Walter Oney are translated into our “great and mighty”.
And one last thing. I am not a great expert in the field of driver development, so errors or inaccuracies, both in this and in all subsequent articles, are very likely. If you find it, feel free to poke your nose. I'll say thank you.
The power manager keeps an eye on energy usage throughout the system. Historically, power management consisted of turning off the monitor and stopping the disk drives from spinning. But this problem is quickly becoming more complex - due to demands for longer battery life in laptops, as well as considerations for saving energy on desktop computers(which are left constantly on) and the high cost of electricity consumed by server farms.
New power management features include reducing component power consumption when the system is not in use by switching individual devices to a redundant state or even turning them off completely (using the power switch). Multiprocessor systems disable individual processors when they are not needed, and can even reduce the clock speed of the processors (to reduce power consumption). When the processor is idle, its power consumption is also reduced since it does not have to do anything other than wait for an interrupt to occur.
Windows supports a special shutdown mode called hibernation, which copies all physical memory to disk and then reduces power consumption to a minimum (laptops can run for weeks in hibernation) with minimal battery drain. Since the entire memory state is written to disk, you can even replace the laptop's battery (while it's in hibernation). When the system resumes from hibernation, it restores the saved memory state (and reinitializes devices). This puts the computer in the same state it was in before hibernation (without having to re-register and start all the applications and services that were running. Windows tries to optimize this process by ignoring unmodified pages (those that are backed up on disk) and compresses the rest memory pages to reduce I/O requirements. The hibernation algorithm automatically balances system I/O and processor throughput. To reduce the need for I/O throughput at higher processor throughput, use more resource-intensive, but more efficient data compression. Sufficient throughput I/O system avoids compression when entering hibernation mode. With the latest generation of multiprocessors, entering and exiting the hibernation state can take only a few seconds, even if RAM The system has a large volume.
An alternative to hibernation is a standby mode, in which the power manager transfers the entire system to the lowest power consumption state (using exactly the amount of energy needed to regenerate the state). dynamic memory). Because memory does not need to be copied to disk, entering this state is faster than hibernation on some systems.
Despite the availability of hibernation and standby states, many users have not gotten rid of the habit of turning off their Personal Computer upon completion of work.
Hibernation is used in Windows to perform a pseudo startup shutdown called HiberBoot, which is much faster than a normal shutdown and startup. When the user commands the system to shut down, HiberBoot logs the user out of the system and then puts the system into hibernation at a point where the system can be logged back in normally. Later, when the user turns the system back on, HiberBoot will resume the system from the user's login point. To the user, this all feels like a very quick shutdown, as most of the system initialization steps are skipped. Of course, sometimes the system needs to be shut down for real to fix problems or install a kernel update. If the system is commanded to restart rather than shutdown, it endures a true shutdown and performs a normal boot.
It is expected that computing devices on phones and tablet computers, as well as on new generations of laptops, will always consume a small amount of electricity. To provide this mode, modern Windows implements a special version of power management called CS (connected standby). CS is possible on systems with dedicated network connection hardware capable of monitoring traffic on a small set of connections using much less power than running central processor. It turns out that the CS system is always on, CS is exited immediately as soon as the user turns on the screen. Connected-mode sleep is different from normal sleep mode because the CS system will also wake up when it receives a packet from a monitored connection. Once the battery begins to run low, the CS system enters a hibernation state to avoid complete battery drain and possible loss of user data.
Achieving long battery life requires more than just turning off the processor as often as possible. It is also important to keep the processor off for as long as possible. The CS system's networking hardware allows the processors to remain off until data arrives, but other events can cause the processor to turn back on. NT-based Windows device drivers, system services, and applications themselves often start for no particular reason, just to check on the status of things. This polling activity is typically based on setting timers to periodically run code on a system or application. Polling based on timer signals can confuse processor-involved events. To avoid this, modern Windows requires such timers to specify a margin of error that allows the operating system to aggregate timer events and reduce the number of separate trigger times for the processor. Windows also defines the conditions under which an application that is not actively running can execute code in background. Operations such as checking for updates or refreshing content cannot be performed only when prompted to run after a timer has expired. The application must defer to the operating system regarding such background activity. For example, checking for updates should only happen once a day or the next time the device has a battery charge. A set of system proxies provide various conditions that can be used to restrict background activity. If a background task requires low-cost network access or user permissions, proxies will not execute the task until the necessary conditions exist.
Today, many applications are implemented with both local code and services located in the cloud. Windows provides the service Windows notifications(Windows Notification Service (WNS)), which allows third-party services to push notifications to a Windows device in CS without requiring CS network hardware to specifically listen for packets from third-party servers. WNS notifications can alert you to time-critical events, such as the arrival of text message or VoIP call. When a WNS packet arrives, the processor will have to turn on to process it, but the CS networking hardware has the ability to differentiate between traffic from different connections, which means that the processor does not have to turn on in response to every random packet coming from the network interface.
Question: When long work computer or exiting sleep mode, the font in the start menu is lost
When the computer is running for a long time or comes out of sleep mode, the Start menu looks like this.
How to fix this? Help me please..
Answer: reinstalled OS already and updated(
Question: How to put the computer into sleep mode type S1 ("Stand by")?
Neither on a desktop computer nor on a laptop can I figure out how to put the computer into sleep mode type S1.
Result of running "powercfg /a"
The following sleep mode states are available on this system:
Standby mode (S3)
The following sleep states are not available on this system:
Standby mode (S1)
Standby mode (S2)
The system firmware does not support standby mode.
Hibernation
Hibernation mode is not enabled.
Standby mode (connected)
The system firmware does not support standby mode.
Hybrid sleep mode
Quick start
Hibernation mode is not available.
Answer: Let the computer sit idle for a couple of minutes, then put it to sleep and wake it up.
In the event log:
Action => create custom view
In the date item, set, for example, a two-minute interval and see what happened.
I have no more ideas.
Well, check the drivers and devices connected to the computer
Question: Wake up from sleep mode at 4am
Almost every night the computer wakes up and wakes me up.
in device manager, network adapters, unchecked the "awakening with magic packages" checkbox.
I disabled wake timers in the power settings.
On the command line, the command powercfg /waketimers is what it shows.
c:\>powercfg /waketimers
The timer set by the legacy kernel caller is valid until 04:14:46 on 01/09/2016.
Cause:
Help. Who is to blame and what to do?
Answer: finally cured this illness:
Control Panel -> Security and Maintenance -> Maintenance -> Automatic Maintenance -> Change Maintenance Settings -> uncheck "Allow a maintenance task to wake up my computer..."
Question: Computer turns on spontaneously at night
Lately (about 1...2 months), approximately 30...60 minutes after putting the computer into sleep mode (so that you can continue working in the morning from the moment it was interrupted), it turns on spontaneously. I finish work around 12 at night, i.e. switching on occurs at 0:30...1:00 am. The monitor remains dark. I get out of bed, move the mouse - the monitor turns on, I enter the profile in normal mode, enter sleep mode again - that night it doesn’t turn on anymore.
The computer has a Win7 system and a resident MS Cecurity Essentials antivirus. I ran the current (freshly downloaded) healing utilities mbar and DrWeb Cureit several times - we found several problems, but the spontaneous activation still remained. It looks like a virus that is connecting my computer to DDOS attacks. Moreover, from time to time Google blocks access due to suspicious traffic coming from my IP. This has been happening for quite some time (more than a year), but I noticed the computer turning on spontaneously only recently.
Actually, the question is: if the problem is known and can be treated relatively simply, then I will download the recommended software, scan it with it and post it. If the problem is more complex, then I won’t fool myself or the local gurus and will stupidly rearrange the system.
Answer: Falconist, there's something I didn't quite understand...
Message from Falconist
after putting the computer into sleep mode... it turns on spontaneously
Sleep mode and hibernation mode in 7 are completely different things. To put it into sleep mode, just press the Sleep button on the keyboard. If you click Start and hover your mouse over the arrow next to Shutdown, a menu will appear that includes Sleep mode. and Hibernation. During hibernation, the computer is disconnected from power in the same way as when shutting down, but when you turn on the computer, you can start working in the same way as after sleep mode.
But you asked about something else. Have you checked the task scheduler?
Question: The computer wakes up from sleep mode at night
Good day everyone. I'm already sick of this problem. The PC itself wakes up from sleep mode at night, it’s Windows 10, before that it was 7, there was no such problem, so I chose this particular section.
What was already done 2 days ago:
1. In the event viewer I found the reason: Timer - The scheduled task "NT TASK\Microsoft\Windows\UpdateOrchestrator\Reboot" will be executed, requesting to wake the computer from sleep mode.
I went to the Task Scheduler, found this task and unchecked the item: Conditions - Wake up the computer to complete the task.
2. Went to powercfg.cpl - Set up power plan - Change advanced power settings - Sleep - Allow wake timers - DISABLE.
Tonight the situation repeated itself, but in the event viewer I found only:
The system has returned from a low power state.
Sleep time: 2016-10-29T21:38:38.657073700Z
Wake up time: 2016-10-29T21:58:34.625754700Z
Output Source: No Data
3. In the device manager, unchecked “allow this device to wake the computer from standby mode” from the mouse, keyboard, network drive, and wherever I found it...
Help me decide this problem, I don’t know where to dig anymore...
Answer:
Message from GoLeMjkeee
Stands daily at 2-00
Change it to daytime.
Message from GoLeMjkeee
but a tick.... not worth it.
10 she is like that, with character.
Question: How can I hide the screen with the "Login" button when exiting sleep mode?
Windows 10 Pro 1607.
When you wake up from sleep mode, Windows asks you to press "Login". Appears upon awakening blue screen with the inscription of the user name and under it the “Login” button. The password is not set, the user is the only one in the system with administrator rights. When loading everything is fine, no screens or button presses, just the desktop.
In Settings- Accounts- Login options do not have the "Login required" option.
In the User Accounts window, on the Users tab, the “Require username and password” checkbox is unchecked.
There is no "Require password on wakeup" option in the power plan settings.
How can I remove the "Login" button when exiting sleep mode so that the computer automatically launches the desktop bypassing this window?
Answer: remove sleep mode
Question: Windows 8.1 turns off in sleep mode
Hello.
I have a problem with sleep mode. The computer turns off completely while sleeping. Those. The power is completely lost. Previously, the light on the system unit was blinking while sleeping, now the mouse also goes out completely with USB, the keyboard goes out and can only be turned on with the power button and of course all the information is not saved.
I've read a lot of topics on the Internet, but not a single problem is similar to mine.
I’ll immediately write down the PC specifications: ASUS p8h67 motherboard, Radeon HD7850 video (asus), intel i5 2550k, 8gb RAM, SSD Silicon Power s55 120gb, HDD WD 500gb.
I installed Windows 8.1, it has been installed for a very long time and sleep mode worked as it should. One day it stopped working, I don’t even know exactly why and after what (some actions) it stopped working. It seems like I didn’t install anything like that, I didn’t seem to update the drivers.
I often, out of habit, press sleep instead of turning it off, and one day it started working and worked for several days, but over time it stopped working.
Tried updating drivers or uninstalling them. I tried to disconnect unnecessary devices from the computer (well, you never know). Disabled various programs before the sleeping person. Nothing helped.
On the Internet I found the only information that is exactly the same as mine (point 8):
Of course, I couldn’t install the drivers, different platforms. I couldn't find the same ones for myself.
I don’t want to reinstall the OS because... everything (except sleeper) works well.
Any ideas what could be wrong?
Added after 17 minutes
I forgot to write that I reset and updated the BIOS.
Answer: Then check either the power supply or the Mother. Programmatically we configured sleep and hibernation powercfg /h on.
Another option is to check (replace). hiberfil.sys - it is responsible for hibernation mode.
Question: Sleep mode in Windows 8
after waking up from sleep windows mode 8 starts to reboot and after windows loading the following message appears
Tell me how to deal with this?
Answer:
Message from azat145
After resuming from sleep mode, Windows 8 starts to reboot
At first.
After.
Question: Hybrid sleep mode or Hibernation? Which is preferable on a desktop?
In general, the question is in the title. As I understand from the search engine, or rather, from the same article copied to all sites, the advantage of Hybrid sleep mode is only in the speed of turning on, waking up, one might say. And if I want to use the Hibernation mode on my desktop Windows 7 x64, are there any pitfalls? I just need to turn off the power, and with Hybrid Sleep mode it’s better not to do this. Thanks to everyone who responds
Answer: I read it today. Okay, in my opinion, there is no other answer to my question than a short briefing from Microsoft. Then I’ll share my conclusions (for those who come across this topic on a similar issue).
So:
pros Hybrid sleep mode: 1. Fast startup, no need to completely turn off the computer;
Minuses: 1. Loads HDD(according to one moderator from Windows partition 7 on our forum); 2. Doesn’t turn off completely, continues to draw current, albeit a little (although for some this point is a plus)
In short, Hibernation is needed if you want to constantly disconnect from the network, but do not want to load/shut down the OS for a long time.
Hybrid sleep mode - for those who are satisfied with a PC that is constantly online.
Question: Previously, the laptop turned off at startup, now it’s in sleep mode
My DELL laptop INSPIRON 3521 with Windows 8.1 used to turn off at startup (the DELL logo appeared - turn off - turn on again and normal operation). I updated the system to 10k, but it didn't help. I took it to the unfortunate service center, well-known and vaunted in the city - there the laptop safely rested from human attention for 2 weeks. Taking it away, I fixed the problem by turning it off fast loading and happily returned to 8.1.
A month has passed, and now, when I close the laptop lid, it goes into sleep mode (as in the settings), but after 20 minutes or a little more it turns off completely (this has never happened before and the power settings have not changed). When you turn it on, the situation is what I described above: turn on - logo - turn off. After restarting, normal operation. All drivers are updated. What could be the problem and how to fix it? I feel sorry for the poor fellow - it’s only been a year and a half, and I have a diploma and state certificates - I can’t drag it around to masters now...
Answer: How do you want it to work? Personally, I use hibernation, not sleep mode, the transition to hibernation when inactive is also enabled, the settings are in the attachment
Transferring power settings
Loading...
