8

I have an WinForms application that keeps track when system enters suspended state (sleep) and when it resumes. App uses the SystemEvents class for this purpose. It works fine on my machine. However it seems that for some users the event with PowerModes.Resume is not always raised. App recieves multiple PowerModes.Suspend without any PowerModes.Resume in between which is strange.

My primary question is how that could possibly happen and how to avoid it and make resume detection reliable?

The code is pretty straightforward and is basically following (very shortened):

Imports Microsoft.Win32


Friend Class TehClass
    Implements IDisposable


    Private Sub New()
        AddHandler SystemEvents.PowerModeChanged, AddressOf Me.System_PowerModeChanged
    End Sub


    Private Sub System_PowerModeChanged(sender As Object, args As PowerModeChangedEventArgs)
        Log.Info("Power mode changed: {0}.", args.Mode)
    End Sub

#Region "IDisposable Support"
    ' just dropping handler there
#End Region

End Class

There is an existing form within app all the time. However it could be minimized or hidden in the notification area. Also there is kept reference to the actual instance of the TehClass.

This is the sample log:

[2015-09-15 22:38:38,501] Power mode changed: Suspend.
[2015-09-16 07:10:31,106] Power mode changed: Resume.
[2015-09-16 08:54:21,112] Power mode changed: Suspend.
[2015-09-16 09:14:36,252] Power mode changed: Suspend.
[2015-09-16 09:35:21,077] Power mode changed: Suspend.
[2015-09-16 09:55:36,085] Power mode changed: Suspend.
[2015-09-16 10:15:50.122] User reported this log therefore the PC had to be in Working (Resumed) state.

What I notice from the log is that there actually was Resume event raised for the first time. Another thing is that suspend got invoked in roughly 20 minutes intervals. Could it be some kind of "computer just partially wakes-up without actually turning monitor on or so and lets apps to process whatever they need to /network notifications, etc./ and than is put into sleep again" stuff?

mancze
  • 669
  • 6
  • 22
  • 4
    Power management is one of the least reliable parts of Windows. Caused by lots of machine builders all using the exact same hardware and OS and only having their own bios and power scheme to distinguish their machine from others. Bugs galore, don't depend on it. – Hans Passant Sep 17 '15 at 08:23
  • And that's why we have .NET, no? Ok, hopes aside. So that's no surprise that above happens? That's really bad because my application suspends some of it's functionality during pc sleep and I need it to resume properly. What's purposed workaround? Polling? – mancze Sep 17 '15 at 09:09
  • @mancze I would try to create a lightweight background thread that check if the system is running every 1 second/minute/hours... whatever is needed, and if the system is running, but the software is still sleeping, then wake it up. – Max Jan 10 '16 at 08:51

1 Answers1

1

Agree with Hans 150%, not a fan of working with Windows power management. Your best bet might be to create a light service that runs at all times and informs your software when it starts back up; it has been awhile but I believe services can fire events as soon as they start running again, at startup, pause, etc...

You could do a mixture of the two and confirm that sleep is the reason the service stops prior to making any log of system suspension. Then use the service startup/resume event to turn everything back on. You could probably put the logging logic into your service depending on what else utilizes this data.

Here is the on continue event info from msdn: https://msdn.microsoft.com/en-us/library/system.serviceprocess.servicebase.oncontinue(v=vs.110).aspx

  • 1
    I understand what do you mean but this seems too be real overkill for my case. Also this approach seems to introduce some more pitfalls - app's dependency on the service, ensurance the service is running, rights needed to install the service, user manually disabling the service,... Yes, I mentioned I need the reliable detection but not that badly :). Though it's nice to have idea here as it might be helpful for someone else. – mancze Jul 11 '16 at 15:11