none
Win10 WDDM DDI call sequence for system sleep hibernate RRS feed

  • Question

  • Is there any documentation or quick way to find out the actual call sequence by Windows (Win10 in particular) to the devices when a system does into sleep, hiberante and fast-startup? In particular for display adapter?

    Obviously DxgkDdiSetPowerState is the important one, but what other DDIs are called?
    Friday, July 10, 2015 12:39 AM

Answers

  • The solution to pretty much all performance problems is the Windows Performance Toolkit (WPT), which is part of the SDK. There are videos on Channel 9 (search for Windows Performance Analyzer, Windows Performance Recorder, WPA, WPR, and XPERF) that will walk you through how to use the tools. You'll also need a pretty good understanding of Windows internals to make the best use of the tools.

    Learning how to use the WPT will definitely take some time, but it is well worth the investment because it can tell you exactly where delays are happening, and - with some digging - why the delay is happening.

    Until you have measurements, it will be very difficult for anyone to help you.

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    Friday, July 10, 2015 4:30 AM
    Moderator

All replies

  • The Power Manager sends out various power IRPs (IRP_MJ_POWER) to all drivers in the system. WDM drivers process these directly, while the various port and class drivers intercept the IRPs and turn them into something specific to that port or class. Driver power management is described here

    What is the larger problem you're trying to solve?

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    Friday, July 10, 2015 3:08 AM
    Moderator
  • We noticed some excessive delay during these sleep/hibernate sequences. At first we suspect it's the device SetPowerState as that's the usual problemetic section. But that turns out ok. So the delay is in some other calls into the device driver, but I don't know which/where to start looking now.
    Friday, July 10, 2015 4:21 AM
  • The solution to pretty much all performance problems is the Windows Performance Toolkit (WPT), which is part of the SDK. There are videos on Channel 9 (search for Windows Performance Analyzer, Windows Performance Recorder, WPA, WPR, and XPERF) that will walk you through how to use the tools. You'll also need a pretty good understanding of Windows internals to make the best use of the tools.

    Learning how to use the WPT will definitely take some time, but it is well worth the investment because it can tell you exactly where delays are happening, and - with some digging - why the delay is happening.

    Until you have measurements, it will be very difficult for anyone to help you.

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    Friday, July 10, 2015 4:30 AM
    Moderator
  • Not directly using WPR, but we are using ADK & WPA. In fact the issue is from the delta between the ADK (which is essentially pre-set logging with WPR?) recorded timing vs our SetPowerState timing. From WPA, within the time logged to our driver, there's periods of time when there's a bunch of DXG call stacks but none from our driver so we don't know where to go from there.
    • Edited by WhyAndrew Friday, July 10, 2015 2:04 PM
    Friday, July 10, 2015 2:03 PM
  • Anything that takes time is usually the result of waiting upon some synchronization object. You'll have to dig deep to figure out what it is waiting on. I believe there are one or two videos on doing just that.

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    Friday, July 10, 2015 5:12 PM
    Moderator