REM !! MUST run as Administrator!! REM Sometimes an active remote client sends requests over the. REM network for no apparent reason. In that case, the command. REM This prevents the condition in which this computer will not go. REM To enable requests again, execute as administrator :. REM This allows requests and thus allows them to prevent this.
The content you requested has been removed. Ask a question. Quick access. Search related threads. Remove From My Forums. Asked by:. Archived Forums. General Windows Desktop Development Issues. Sign in to vote. Sometimes I to go into the Power settings control panel and re-apply the sleep settings, then manually put the system into sleep mode.
The system will wake and sleep normally again for a while, until it thinks there is another "active remote client". I have a script that runs as an hourly scheduled task. If there are no requests to not sleep, and the settings are to sleep after 15 minutes, why would it not sleep?
I just came across this thread regarding Powercfg reporting "An active remote client has recently sent requests to this machine" which blocks sleep mode. I had the same problem and fixed it. Since this thread is months old, hopefully you found the solution to this already. If not and for those who like me who just found this post. This may be the answer, it worked for me:. By default, Windows 7 will attempt to prevent system standby when connected to a remote share or file.
Presumably, this is to prevent any ongoing file transfers over the network from failing due to the system unexpectedly entering standby. But there are many cases where the system is connected to a remote share and it is okay to enter standby. Windows 7 includes a setting to allow the computer to enter standby, but it may be missing from the advanced power options dialog box. Try creating and then leaving a Homegroup between the machine having the sleep problem and the other s keeping it awake.
I developed the same insomnia problem described here on one of my networked group of Windows 7 machines after enabling media streaming but declining to create a Homegroup when the option to create one was presented during the media streaming setup process.
I struggled with various solutions, all to no avail, except disconnecting the problematic machine from the others on the network not a solution. Ultimately I determined that certain other machines on the network would keep the problematic machine awake. I was able to identify the affected machines by disconnecting various combinations of machines from the network until the problematic machine slept normally.
Ultimately, the problem disappeared after I created a Homegroup, joined all the affected machines, and then left the Homegroup from all machines. After a forced sleep using the shutdown menu on all the affected machines, and subsequent manual wake, they now all sleep and wake normally, as expected, according to the power plan settings.
I suspect that by declining to create the Homegroup when prompted, it leaves some inchoate remnant of Homegroup creation lingering around on one or more machines, which in turn results in repeated requests being sent from one machine to the other, keeping the other awake. BTW I monitored the powercfg requests using the following batch file, run as administrator:.
The above fix didn't hold up. Worked for me too - i. Still get the magic message as below. Microsoft Windows [Version 6. All rights reserved. I tried changing power options for the network adaptor, updated the driver, left the homegroup and the problem wouldn't go away. It was puzzling because there were no other computers on my network - they were all shut down but still I was getting the "active remote client request So I disabled my network adaptor expecting to narrow down the problem to the network adaptor but to my surprise the same error occurred How could an active remote client make a request when the network adaptor was turned off and I wasn't even on the network.
That's where I found the solution to my problem. I use a program called Sync2 to synchronise my MS Outlook calander with my google calendar on my phone.
I had recently upgraded Sync2 and it failed to accept the previous configuration so the default synch schedule had it trying to synchronise every 15 minutes.
I changed it to once daily and my problem dissappeared. My system now goes into standby as expected. I had the same problem after upgrading my Vista machine to Windows 10 and joining a Homegroup: "An active remote client has recently sent requests to this machine".
I struggled to see how the Homegroup could be the source of the problem, since "powercfg -requests" reports the above, even when the other Homegroup computer is sleeping.
I have exact same problem. Had it with Win 7, upgraded to Win 10, no change to the "An active remote I tried the Allow Computer to Sleep option while plugged in When sharing Media as indicated above, but that did not solve the issue. I tried then Disabling the Plugged in option under Allow Wake Timers and that finally solved the disturbing issue! Thanks for the clue anyhow. Is there no way to ignore just the request? And leave the open file alone? Office Office Exchange Server.
Not an IT pro? Windows Client. Sign in. Hi, According the issue, please try to use powercfg command line to check whether these devices support waking from deepest sleep S3. Tuesday, January 17, AM. Updated NIC or Wifi card drivers? Tried this but still no luck. Only works if I press the Power button. What make of PC or motherboard is it? Thursday, January 12, PM. In device manager, make sure the "Allow this device to wake the computer" flag is turned on in the power management Tab for your particular device.
If that doesn't work, please feel free to post more information about your hardware setup. Friday, January 13, AM. Latest BIOS flashed onto it. Also tried all the ports on the computer, with no success.
Yup, this is already enabled. Sunday, January 15, AM. Hi, I am currently standing by for an update from you and would like to know how things are going. Friday, January 20, AM. Thursday, July 19, PM.
0コメント