LatencyMon: A top-end system struggles with processing live sound?
LatencyMon: A top-end system struggles with processing live sound?
Your configuration is acceptable. The required action was to remove the dump. Honestly, it's not helpful to erase error logs and dumps since you'll need them eventually.
I wanted to note a few observations from that dump.
I noticed an older driver named EL_Display_vhidbus.sys, which is quite dated—dated back to 2021.
Rich (BB code):
0: kd> lmDvmEL_Display_vhidbus
View full module list
start end module name
fffff802`2e9a0000 fffff802`2e9ad000
EL_Display_vhidbus (deferred)
Image path: \SystemRoot\System32\drivers\EL_Display_vhidbus.sys
Image name: EL_Display_vhidbus.sys
Explore all global symbols, functions, data, Symbol Reload
Timestamp: Tue Jun 29 04:16:03 2021 (60DA7453)
CheckSum: 0000E8F8
ImageSize: 0000D000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Details from resource tables:
This isn't a typical driver we encounter, so I looked it up. It seems to be part of WindowexeAllKiller? Please confirm you don't have that installed. It appears to advertise itself as a junk file cleaner, but it looks extremely risky to me, and I would never suggest using such a tool. What was its purpose? From reading the instructions, it's evident that using it could cause serious harm. If it has an undo option, I'd use it and revert all changes before uninstalling. Misuse might be the source of your latency issues.
Additionally, there are other aspects worth considering—whether this dump was taken during audio latency problems, or if the longest-running DPCs at that time could help pinpoint causes. We can retrieve WMI traces from the dump and convert them into a format the Windows Performance Analyzer (WPA) can read. This would let us identify long-running DPCs that might be contributing to your performance issues. The longest running ones in this dump are:
Code:
nvlddmkm.sys 8.122167 ms
MpKslDrv.sys 6.398402 ms
tcpip.sys 2.775793 ms
Wdf01000.sys 1.346372 ms
dxgkrnl.sys 1.054072 ms
storport.sys 0.359704 ms
Microsoft advises that no DPC should exceed 100μs (0.1ms), and all listed ones do, though some run longer than recommended. We can rule out dxgkrnl.sys and nvlddmkm.sys as likely candidates since they often run longer during streaming. The tcpip.sys and storport.sys drivers (along with stornvme.sys) suggest you might have been streaming at the time, which is common for these DPCs. The Wdf01000.sys driver serves as the root driver for all those using Windows Driver Foundation libraries—so it could be any third-party driver relying on WDF libraries. We frequently see this driver running slightly longer, which makes me consider it too.
The other point is the MpKslDrv.sys driver, which belongs to Windows Defender and isn't typically seen running that long. Are you using any antivirus software (Avast, Malwarebytes, etc.)? I don't see their drivers loaded, but that doesn't necessarily mean they're not installed. Multiple real-time protection products can cause conflicts.
This might just be a coincidence, but it largely depends on when the dump was taken and what Windows Defender was analyzing at that moment.
Seeing WindowsexeAllKiller installed makes me wonder if this problem could have been caused by your own actions.
Thank you for the information. I think the EL_Display_vhidbus.sys is responsible for the easy canvas app on the iPad. It allows the device to act like a graphics tablet with a display. The software can be found at https://easynlight.com/en/easycanvas. The easy and light display hub is also turned off in the device manager. I only have Windows Defender and Windows Firewall installed, with no other antivirus or firewall. The spikes keep occurring, so I expected them to appear, but I plan to run another dump without any processes running and then create a new one right after a spike.
msmpeng.exe was also appearing in some latency logs—it was detected as Defender. Would it help to run autoruns and capture a screenshot? Considering checking the driver section? Autoruns lists all applications that launch with Windows. You can find it here: https://learn.microsoft.com/en-us/sysint...s/autoruns. It’s recommended to open it with administrative privileges for safety. Clicking the driver tab might display something similar. Currently, I’m not sure what to do further. Just sharing a screenshot would be enough. Image posting via Imgur go here - https://imgur.com/ you might need to create an account. Click on New Post which will open the next screen where you can upload images—hold Ctrl while selecting files in Explorer to view multiple. After uploading, the images appear on the following page. Right-click an image (once displayed) to proceed. Forums. Autoruns can assist in removing or temporarily stopping drivers with Windows. It might provide useful insights. I’m unsure how much Ubuysa can see, so that’s another point. Note: rspLLL64.sys is the driver associated with latencymon. I was curious since unknown drivers often appear in high-latency reports—someone might be trying to attribute the issue to the tool. Alternatively, you can download and use Driverview: http://www.nirsoft.net/utils/driverview.html It simply examines installed drivers; it won’t install any (this is intentional, as third-party driver updaters sometimes make mistakes). When using it, go to the View tab and hide all Microsoft drivers. This shortens the list. Now it’s up to you—review the drivers and look for outdated ones or take a screenshot including the driver name and creation date. Upload the image to an image-sharing site and share the link here. It displays every installed driver, not necessarily those actively running. Not all drivers are required at startup, unless necessary. Note: Forum software isn’t perfect; there’s no character limit on posts, so I’m limiting the latency report details or adjusting the length accordingly.
Testing them using this link: https://support-en.wd.com/app/answe...iv...rn-digital
Thanks for the info on EL_Display_vhidbus.sys, it sounds less dangerous now!
I wouldn't bother taking more manual dumps, the chances of you catching anything useful is pretty low.
I now nothing about that Focusrite audio device but the ISR code and DPC code (which is what leads to 'latency') are in the device drivers. The ISR code (the front-end of device interrupt processing) is given control when a device presents an interrupt, the ISR designed to run quickly, ideally in 25μs. All the ISR does is store the buffer location, schedule a DPC, flag the device interrupt complete, and then return. The DPC (the back-end of device interrupt processing) is placed on a queue with other DPCs, the queue is executed when a processor is otherwise idle. The DPC accesses the buffer and handles all the necessary processing to move data etc. to complete the device interrupt. The DPC is where the bulk of interrupt processing is done.
In your Latencymon report the DPC times are reasonable, only a handful run longer than 100µs...
Code:
Total time spent in DPCs (%) 0.036115
DPC count (execution time <250 µs): 760600
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-10000 µs): 95
DPC count (execution time 1000-2000 µs): 1
DPC count (execution time 2000-4000 µs): 0
DPC count (execution time >=4000 µs): 0
There are only 96 DPCs that run long and 760,600 that run in a reasonably short time. Those 96 outliers could be causing problems, but I don't think that 0.012% of DPCs running long is going to generate the sort of bad audio issues you report.
Incidentally, ntoskrnl.exe is neither a driver nor a DPC even though it appears in these reports. It's the Windows kernel and we expect it to run long.
It's a similar picture with the ISRs, the reported ISR times are generally reasonable...
Code:
Total time spent in ISRs (%) 0.000576
ISR count (execution time <250 µs): 67737
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-1000 µs): 0
ISR count (execution time 1000-2000 µs): 0
ISR count (execution time 2000-4000 µs): 0
ISR count (execution time >=4000 µs): 0
All of the ISRs seen ran within the normal limit (although 250µs is long for an ISR). I'm starting to think that this isn't an ISR/DPC issue necessarily. That means it's either an issue with the Focusrite device or its drivers, or it's those hard page faults I mentioned already.
In case you don't know, a page fault occurs when a reference to a virtual storage page is made and that page is no longer active. If the page is still in RAM - on the Standby list - then the page is simply re-activated and the process continues. These are known a soft page faults. A hard page fault is where the page is no longer in RAM and has been written to the pagefile. This requires an I/O to the storage device to recover the wanted page and that takes time, during which the process waiting for that page is delayed (more latency).
Pages are written to the pagefile for several reasons. An application can request that pages are paged out, it might do this if it's unlikely to need these pages again - pages containing error handling code or program initialisation code for example. The Windows memory manager will steal pages that it detects are being unused - Windows measures how often each RAM page is referenced, unreferenced pages are liable to be stolen. If there is plenty of RAM these stolen pages are typically left in RAM and placed on the Standby list but there are times when they can be directly paged out to the page file.
In your Latencymon report there are a large number of hard page faults, more than I would expect in a 96GB RAM system. These could easily be related to the poor audio performance if these pages were related to an audio app or the Focusrite device/app. You can open the Resource Monitor (enter resmon in the Run command box), expand the Memory section, and then click on the Hard Faults/sec header to sort on that column - so that the processes with the highest Hard Fault/sec rate are at the top. If you leave this display running you should be able to see which processes are taking hard page faults and whether these correlate with your audio glitches.