Having Open Network, TC Keeps PC From Sleeping

[RBraverman]

If you find a computer on the network via the network neighborhood, then exit (the panel - not TC) it will not go to sleep. If you run a quick powercfg /requests, TC is the cause.

[ghisler(Author)]

???
This doesn't make any sense. Does powercfg tell you what TC is doing on that PC?

[gdpr deleted 6]

Please consider this post to be merely informal, in case somebody wants to investigate this issue any further.

I am not sure whether TC is being the culprit or whether some 3rd-party software of some network-related component of the OS is causing this, or whether this issue would be specific to particular Windows OS versions or not...

I can reproduce the reported behavior, but only under certain circumstances. So far, i can only observe it when i connect to a network resource where my local Windows has to provide user credentials to authenticate access to the network computer/network share.

If this happened, "powercfg -requests" will show the following:

Code: Select all

DISPLAY:
None.

SYSTEM:
[DRIVER] ASUS Xonar Essence STX Audio Device (PCI\VEN_13F6&DEV_8788&SUBSYS_835C1043&REV_00\5&1e9a2d6a&0&2000E0)
An audio stream is currently in use.
[PROCESS] \Device\HarddiskVolume2\Program Files\Total Commander\TOTALCMD64.EXE

AWAYMODE:
None.

(Ignore the entry about the sound card. This should not be related to the issue but to me listening to music while testing this issue...)

Quitting TC will (obviously) remove the power request.
Starting TC again and accessing the same network resource again will not make the issue reappear.

My tests were not that extensive. What would still need to be tested by someone to get a better picture about the situation:
- Does the same issue occur if the initial access to and authorization for a network computer/share is being done by other means such as Windows Explorer or "net use"?
- Does it matter whether the OS uses stored user credentials for accessing the network resources, or whether the OS has to request the credentials from the user?
- Does the issue occur only with the first accessed network resource requiring authentication, or will it reoccur with access to any other network resources that would also require exchange of credentials?
- Do different power plans (desktop/mains power vs. laptop/battery power plan) alter the observed issue?

Again, from my observations it is currently inconclusive whether the issue is caused by TC or by some other software component unrelated to TC's code base.

OS: Windows 7 Pro x64 english
TC: TC64 9.0a

[ghisler(Author)]

Audio stream? Maybe you opened a file with F3, so it was played with the internal player or a plugin?

[gdpr deleted 6]

Audio stream? Maybe you opened a file with F3, so it was played with the internal player or a plugin?

As i said right underneath my output of powercfg:

(Ignore the entry about the sound card. This should not be related to the issue but to me listening to music while testing this issue...)

To answer your question, the player is foobar2000 which was not started by/from within TC. The sound-related power request is not related to the power request by the TC process at all, hence why you can ignore it... (EDIT: Come to think of it, it could perhaps also have been a youtube video stream playing or being paused in the web browser. Still, ignore the sound-related stuff, please... )

[ghisler(Author)]

What call would cause such a lock? I'm not aware of calling anything specific which could cause this...

[gdpr deleted 6]

What call would cause such a lock? I'm not aware of calling anything specific which could cause this...

I have no idea. Assuming that TC's code would cause this -- and i am only assuming this here for the sake of providing an example --, a reason could be bug that causes a "rogue" call of SetThreadExecutionState setting a continuous execution state under certain circumstances. Or perhaps SetThreadExecutionState for setting a continuous execution state is being called as part of the normal program function, but the associated call of SetThreadExecutionState for resetting this continuous state is not being called from the same thread.

But then again, there can be other reasons for this issue that could be more or less unrelated to TC's code base. It might be that some 3rd-party DLL loaded by TC or perhaps the specific implementation of some Delphi or Lazarus API causes this. Or perhaps there is some other funky thing going on.

I did a few tests with two little quick&dirty C programs, only using WINAPI functions to access the same remote PC that causes the problem with the power request for me. One program uses NetShareEnum to enumerate the network shares of the remote PC, the other program uses WNetOpenEnum/WNetEnumResource. Unfortunately, neither of these two programs caused a power request. Without knowing TC's code base it is pure blind-guessing about what exactly is the chain of events, API calls and/or involved (system) components that could lead to this power request.

Not sure if resolving the issue using "powercfg --requestsoverride" could work. Overriding/suppressing power availability requests from TC could perhaps lead to a laptop going into sleep/standby while a (unattended) file copy/move job is active...

[ghisler(Author)]

I'm not calling SetThreadExecutionState. It could be either a plugin, or an Explorer extension (e.g. from opening a right click context menu or so). Does this happen only after using a specific function?