DPS Consuming All of Memory upon Resume with HORM RRS feed

  • Question

  • Looking for any thoughts on this, and also wanted to document this in case others ran into it...

    I'm debugging a problem with a Windows Embedded Standard 7 system, resuming from HORM.

    The problem is that all of memory and CPU is consumed by the Diagnostic Policy Service (DPS) starting suddenly about one minute after resume from hibernate and lasting between 10 and 60 seconds. This results in an out-of-memory popup message, app crash/instability, or no outward/visible effect, depending on the date/time (CMOS clock).

    I've spent a lot of time debugging this and collecting data with tools, custom apps, etc. I'll bullet point some specifics, but I'll leave out some of the gritty details; if you think the details might help provide any clues, I'd be happy to provide those too.

    - if DPS is stopped immediately upon resume, memory and cpu are stable until restart.
    - the duration [and severity] of cpu/memory consumption is strongly correlated to the real time clock (time/date).  A plot of available system memory versus date shows that the problem gets worse with time until 256 days from the HORM state creation. After that, the problem no longer occurs.  See image; note that the zero values are just markers indicating memory was critically low and resulted in the outward symptom.  This test was continued out through 2016 with the same result (no memory consumption after the 256th day)
    - the Explorer shell has been replaced by a small custom app, but when the app is exited immediately after resume, the problem still occurs.
    - the WES7SP1 DS was updated through October 2013 with WEDU

    At this point, there are some possible workarounds, but I don't understand the core problem and I need to.

    I have found very little information about what DPS does.  What might trigger it to behave like this?  How does it use the real time clock? 

    Any insights or thoughts would be appreciated.

    Thanks in advance,

    Availabel memory versus clock


    • Edited by Erik_J Friday, February 7, 2014 3:08 PM
    Thursday, February 6, 2014 5:11 AM

All replies

  • "The Diagnostic Policy service enables problem detection, troubleshooting, and resolution for Windows components."

    What happens when you disable the service completely? / / Book Author - Pro Guide to WE8S, Pro Guide to WES 7, Pro Guide to POS for .NET

    Friday, February 7, 2014 5:35 PM
  • Sean, thanks for the response.

    Disabling the service before entering the HORM state has the same result as stopping it upon resume: no symptoms of failure.


    Friday, February 7, 2014 6:05 PM
  • Another experiment...

    Available memory is recorded once per second for 90s after resume from hibernation, then the clock is advanced one hour, the system restarts and repeats.

    The graph shows two trends; both show memory consumption increasing linearly with respect to time.  One is "quick" and does not recur after the 28th day after hibernation.  The other is "slow" and, extrapolating out, I'm guessing this brings memory consumption to near 100% in about 256 days (as seen in the previous experiment).

    Mem consumption over time; two trendsconsumption is pretty linear with time


    Monday, February 10, 2014 4:23 PM
  • More info and test results (and a ping for the thread!)...

    The experiment was repeated using an image generated with IBW and the answer file only.  The only changes made to this system were to disable the user account expiration and change the WinLogon shell to be "cmd.exe" rather than "explorer.exe".  The answer file/DS/IBW image contains no hardware specific drivers or other non-Microsoft software and the system has never been connected to a network.

    The results were the same: low memory error reported around the 28th day after HORM and catastrophic failure on the 256th day after HORM.  The start date does not seem to matter (have seen it with various hibernation dates).

    I feel pretty confident that this is a Windows 7 / DPS problem, but it's possible it's related to the specific hardware and/or the ICE answer file.  It is also pretty clear that the problem can be avoided if DPS is disabled.

    The target system is always disconnected from a network and used solely to run a LabVIEW application with no user interaction with the Windows desktop/OS desired.  We don't want Windows troubleshooter to launch, even in the event of a failure.

    What little I have found out about DPS indicates that it should be safe to disable, but it is still unclear what functionality it provides (and what dependencies may fail if it is disabled).

    Does anyone know of any reason that DPS can not be disabled?




    Monday, February 24, 2014 4:26 PM
  • There has been no resolution to this issue and no responses that would give us more confidence in a fix or work-around.  These questions should have straightforward answers for someone with knowledge of DPS and/or WES7.  Does Microsoft participate in this forum?

    What services does DPS provide?

    What are the "cons" of disabling it (in a kiosk-type, disconnected application)?

    Are there known defects/fixes applicable to this configuration (DPS, non-Explorer shell)?


    Friday, March 14, 2014 3:51 PM