High DPC Latency (nvlddmkm.sys, dxgkrnl.sys, Wdf01000.sys, ACPI.sys)

L

levider

Member
Joined
Dec 8, 2018
Posts
14
Hello guys
I have huge problem with high DPC latency on my Omen laptop

1. I reinstalled Nvidia drivers (now without PhysX, only main driver)
2. I tried to disable Device Manager > Battery > something called battery control to solve ACPI.sys problem. And it worked, but my second monitor doesn't work :/

_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be having trouble handling real-time audio and other tasks. You are likely to experience buffer underruns appearing as drop outs, clicks or pops. One or more DPC routines that belong to a driver running in your system appear to be executing for too long. One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates.
LatencyMon has been analyzing your system for 0:02:42 (h:mm:ss) on all processors.


_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name: LAPTOP-DRKJPTJH
OS version: Windows 10 , 10.0, build: 17134 (x64)
Hardware: OMEN by HP Laptop, HP, 8259
CPU: GenuineIntel Intel(R) Core(TM) i5-7300HQ CPU @ 2.50GHz
Logical processors: 4
Processor groups: 1
RAM: 8077 MB total


_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed: 2496 MHz

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.


_________________________________________________________________________________________________________
MEASURED INTERRUPT TO USER PROCESS LATENCIES
_________________________________________________________________________________________________________
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.

Highest measured interrupt to process latency (µs): 3244,301037
Average measured interrupt to process latency (µs): 13,158952

Highest measured interrupt to DPC latency (µs): 3236,506182
Average measured interrupt to DPC latency (µs): 3,636769


_________________________________________________________________________________________________________
REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.

Highest ISR routine execution time (µs): 491,963942
Driver with highest ISR routine execution time: ACPI.sys - Sterownik ACPI dla systemu NT, Microsoft Corporation

Highest reported total ISR routine time (%): 0,006677
Driver with highest ISR total time: ACPI.sys - Sterownik ACPI dla systemu NT, Microsoft Corporation

Total time spent in ISRs (%) 0,012927

ISR count (execution time <250 µs): 7142
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-999 µs): 4
ISR count (execution time 1000-1999 µs): 0
ISR count (execution time 2000-3999 µs): 0
ISR count (execution time >=4000 µs): 0


_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.

Highest DPC routine execution time (µs): 2323,189904
Driver with highest DPC routine execution time: nvlddmkm.sys - NVIDIA Windows Kernel Mode Driver, Version 417.22 , NVIDIA Corporation

Highest reported total DPC routine time (%): 0,085625
Driver with highest DPC total execution time: nvlddmkm.sys - NVIDIA Windows Kernel Mode Driver, Version 417.22 , NVIDIA Corporation

Total time spent in DPCs (%) 0,422731

DPC count (execution time <250 µs): 285098
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-999 µs): 319
DPC count (execution time 1000-1999 µs): 4
DPC count (execution time 2000-3999 µs): 4
DPC count (execution time >=4000 µs): 0


_________________________________________________________________________________________________________
REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.

NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.

Process with highest pagefault count: latmon.exe

Total number of hard pagefaults 598
Hard pagefault count of hardest hit process: 422
Number of processes hit: 15


_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 10,463318
CPU 0 ISR highest execution time (µs): 491,963942
CPU 0 ISR total execution time (s): 0,078858
CPU 0 ISR count: 6069
CPU 0 DPC highest execution time (µs): 2323,189904
CPU 0 DPC total execution time (s): 2,611212
CPU 0 DPC count: 278151
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 2,031970
CPU 1 ISR highest execution time (µs): 90,870994
CPU 1 ISR total execution time (s): 0,003447
CPU 1 ISR count: 637
CPU 1 DPC highest execution time (µs): 413,272436
CPU 1 DPC total execution time (s): 0,070354
CPU 1 DPC count: 3115
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s): 2,661673
CPU 2 ISR highest execution time (µs): 22,421474
CPU 2 ISR total execution time (s): 0,001042
CPU 2 ISR count: 242
CPU 2 DPC highest execution time (µs): 279,509615
CPU 2 DPC total execution time (s): 0,021926
CPU 2 DPC count: 1688
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s): 2,487784
CPU 3 ISR highest execution time (µs): 3,746795
CPU 3 ISR total execution time (s): 0,000444
CPU 3 ISR count: 198
CPU 3 DPC highest execution time (µs): 409,529647
CPU 3 DPC total execution time (s): 0,036582
CPU 3 DPC count: 2471
_________________________________________________________________________________________________________


Driver file Description ISR count DPC count Highest execution (ms) Total execution (ms) Image base Image size Company Product Version Path
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------DPC 2.pngDPC.png
 
I set Power Management Mode to Prefer Maximum Performance in Nvidia Control Panel and it helped lower DPC latency, but still it's too high. So maybe high DPC latency is connected with Nvidia drivers
 
So I came back to older drivers from HP website and now everything looks better. The last thing to do is lower ACPI.sys latency
Any ideas?
 
Hi levider,

ACPI.SYS is usually used by Windows to talk to the motherboard. I'd check the HP product support site to make sure you're using the latest BIOS. I've seen HP's have high ISR/DPC latency when checking the battery status, for example. If you have any system monitoring tools running which directly communicate with the motherboard they could also cause issues, I would imagine. Fan speed, temperature, overclocking tools, etc.

Are you actually experiencing symptoms of ISR/DPC latency such as audio/video glitches?
 
Sometimes I hear crackles

The first thing that I observed on my Omen is System Interrupts process which sometimes takes 5%-10% of my processor usage. It causes my laptop running at full speed and I have to sleep/restart my device to get rid of it.
I read somewhere that it can be related to high DPC latency and here we are. DPC checker shows that something is wrong, but I can't fix it :(

My BIOS is updated, at least that shows HP website
 
Is the battery easily removed? If so, have you tried it with the battery removed?
 
My immediate thought would be refresh rate differences between the displays causing vsync interrupts to fire at irregular times. Are the refresh rates different for the two displays? If so, can you try making them the same or multiples of each other? One at 120Hz and the other at 60Hz, for example.
 
They were different: Laptop 60Hz and Monitor 59Hz
Monitor has 60Hz and 59Hz options but both doesn't change anything in High DPC Latency :/

Should I uninstall Intel Rapid Tech to get rid of iaStorA.sys?
 
Personally, I don't use IRST and uninstall it on systems unless it has been used to create a RAID array. I've seen older versions of IRST cause problems on Windows 10 computers so if you want to keep it I'd suggest making sure you're using the latest version compatible with your system. Those problems are usually BSOD's, though.

It might be worth getting an ETL trace so we can see what the system is doing over time. If you'd like to do so I'd suggest the following:


  1. Open an elevated command prompt.
  2. Exit or uninstall LatencyMon because it seems to add to the DPC latency when running
  3. Run the command wpr -start GeneralProfile and leave the command prompt window open
  4. Use the computer as you normally would for a minute or so and see if you can trigger audio glitches
  5. From the same command prompt run the command wpr -stop c:\result.etl (or change the driver letter to whatever is appropriate for your system) and let it finish processing the trace

If you'd like someone here to have a look at the trace you'll probably need to make it available via a cloud drive or file sharing service as they can get quite large - even when compressed.
 
I see periodic ISR and DPC storms (mostly involving ACPI) which are running long enough to be causing audio glitches. From what I can see in the stacks I think they are mostly performing operations with the battery. I'm not sure if it's representative of the problems you're typically having but I don't really see a problem with individual DPC's or ISR's taking too long. I'm mainly seeing sequences of ISR's and DPC's running one after the other to the point of starving user processes of CPU time on core 0. Core 0 is typically where audio playback threads are scheduled which means you'd get noticeable audio glitches. I see at least 17 instances of such a storm happening in the trace.

Were you experiencing audio glitches during the trace?

Do you only have the problem when the AC adapter is disconnected?

Is your system using an HP power configuration utility? If so, can you disable or uninstall it? If not, perhaps you can try disabling the battc.sys driver using msconfig or autoruns. I've not actually done that before so I'd suggest creating a restore point before disabling the driver and making sure you know how to rollback to that restore point if Windows becomes unbootable.

The screenshot is of Media Experience Analyzer with your trace open. The green swath shows an ISR/DPC storm that lasted 10 ms; 5 ms is considered enough to cause a noticeable audio glitch.

​
 

Attachments

  • 2018-12-11.jpg
    2018-12-11.jpg
    166.7 KB · Views: 9
Last edited:
I didn't hear any audio glitches during the test. But I sometimes hear them when I watch YT or in Kodi app. For sure it's not often
AC adapter? - idk to be honest, I don't remember

"Is your system using an HP power configuration utility?" I don't think so.
Like I said in my first post, I disabled ACPI battery control (or something like that) and since then ACPI.sys wasn't a problem with high latency.
https://ibb.co/WWv0nTq
But my second monitor (I have LG 23" and laptop display is disabled) stopped working after this trick


I will try to disable battc.sys ,but not today, because I don't have enough free time :)
 
I should have asked if you were playing audio. If not, there wouldn't be pauses in playback of audio so you wouldn't hear glitches. Were you playing music or any audio during the trace?

Thank you for letting me know you wouldn't be able to test today. I'll continue looking at the trace to see if I can drill down further. I don't consider myself an expert with trace analysis but I'm trying to learn as much as I can.

Please do let us know what you find out.
 
Last edited:
Autoruns has a Find function which you can use to search for "battc". I don't have a laptop to try it so I'm not sure it will work.

Just to repeat, please make sure you create a restore point and know how to roll back to it if the system becomes unbootable after disabling that driver.
 
I tried using autoruns on an old Windows tablet which Device Manager says is using battc.sys but it's not showing up in autoruns, either. Perhaps it's dynamically loaded rather than automatically loaded at boot. Or it's not something Windows wants disabled.

Just to eliminate it as a possibility can you fully uninstall any and all Avast software and just use Windows Defender; at least while troubleshooting? It seems to load quite a few drivers and I've seen some systems with Avast installed having problems recently.​
 
From what I can tell the system process is checking the state of the battery fairly regularly which seems to be triggering ISR/DPC storms and I'm trying to imagine what could cause that other than a hardware problem. Perhaps Avast checks calls to the UEFI/BIOS but I don't know for sure. It seems possible, though, since UEFI/BIOS attacking malware supposedly exists. Uninstalling Avast, rebooting, and then seeing if the system interrupts still run hot is what I wanted to check.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top