Persistant BSOD: My adventures with HDAudBus.sys

BiggestMunchkin

Distinguished
Jun 13, 2012
38
0
18,530
Hi all,

Since around December I've been encountering a persistant Blue Screen of Death. It's been infrequent enough that I've largely been able to ignore it, but today I lost a significant amount of work due to the crash and that was the last straw.

By persistant, I mean that at least one every few days, and in some periods multiple times a day, I get a BSOD with a KERNEL_SECURITY_CHECK_FAILURE message.

WhoCrashed? always pins the blame on either ntoskrnl.exe or ntkrnlmp.exe, as below:

On Tue 03/04/2018 20:39:19 your computer crashed
crash dump file: C:\WINDOWS\Minidump\040318-7625-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x175510)
Bugcheck code: 0xA (0xFFFFF80390C060E8, 0xD, 0x1, 0xFFFFF8039495F2A4)
Error: IRQL_NOT_LESS_OR_EQUAL
file path: C:\WINDOWS\system32\ntoskrnl.exe
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: NT Kernel & System
Bug check description: This indicates that Microsoft Windows or a kernel-mode driver accessed paged memory at DISPATCH_LEVEL or above.
This appears to be a typical software driver bug and is not likely to be caused by a hardware problem.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.



On Tue 03/04/2018 20:39:19 your computer crashed
crash dump file: C:\WINDOWS\memory.dmp
This was probably caused by the following module: hal.dll (hal!HalPerformEndOfInterrupt+0x186)
Bugcheck code: 0xA (0xFFFFF80390C060E8, 0xD, 0x1, 0xFFFFF8039495F2A4)
Error: IRQL_NOT_LESS_OR_EQUAL
file path: C:\WINDOWS\system32\hal.dll
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: Hardware Abstraction Layer DLL
Bug check description: This indicates that Microsoft Windows or a kernel-mode driver accessed paged memory at DISPATCH_LEVEL or above.
This appears to be a typical software driver bug and is not likely to be caused by a hardware problem.
The crash took place in a standard Microsoft module. Your system configuration may be incorrect. Possibly this problem is caused by another driver on your system that cannot be identified at this time.


During my first round of trying to solve this problem, I managed to trace the issue to a driver. I noticed that the issue usually (maybe only, I'm not 100% sure) occurs when audio is playing. This, combined with reports from Latencymon point to HDAudbus.sys as the culprit.

Here are the Latencymon driver readings when there is no audio playing (after 1 minute):

image.png


And here are the readings when audio is playing (one Youtube video, after 1 minute):

image.png


And, unsurprisingly, when I disable the Realtek High Definition Audio, the ISR and DPC count stays at 0.

Here are some of the things I've tried, multiple times each in fact:

- Windows 10 Updates
- Latest Realtek driver updates from Motherboard manufacturer website (Gigabyte: GA-Z87-D3H),
- Latest from Realtek Website.
- Rolling back drivers to penultimate versions available
- Reflash Bios
- Windows 10 Refresh
- Windows 10 Clean Reinstall
- Removing USB devices

Nontheless, it persisted.

Here is a OneDrive link to the latest minidump file, in case anybody can make use of it


Can anybody point to a possible solution that I've missed, a culprit that I haven't guessed at yet, or a suggestion of where to go now?

Am I looking at a hardware failure? If so, is getting a discrete audio card likely to fix the problem, or will it require a new motherboard?

Any and all help *incredibly* gratefully received, I'm really at my wits end with this. Anything else I can find or do to help with the diagnosis/prognosis, just let me know.

Thanks again.
 
Solution
the last dump was a minidump with verifier turned off. you should provide a kernel dump with verifier turned on. It will contain the internal error logs and more info.

checksums/tmestamps removed from some files. win32k and win32kbase drivers

Well, it's definitely bad audio drivers, unless something NEW is conflicting with the audio drivers causing them to spaz out like that.

Double check WhoCrashed, look a few entries down, as NTOSKRNL = Windows itself, so duh it crashed, and HAL points to a hardware issue, and further down would likely point to the actual culprit. (probably the realtek drivers) Maybe make sure your other drivers are up to date as well... and uhh maybe try a different audio device? (speakers/headphones/microphone maybe the cause?)
 

BiggestMunchkin

Distinguished
Jun 13, 2012
38
0
18,530
Thanks for the tips!

The above is the only report WhoCrashed gives me (I only have the free version). I'll try out bluescreenview, thanks for the suggestion.

My other drivers are all up to date (according to the Windows automatic 'update driver' feature, haven't done a manual hunt for them all).

I'll try switching out the speakers, but I have a vague recollection of trying that already to no effect...

 


Windows update shouldn't be your driver authority.
Just google your motherboard model and you'll find the manufacturers page and there will be a "drivers" button right there and if not there will be a "support" button and under there will be the drivers.

Also, it could be something wrong with your ram/ram settings:
http://www.tomshardware.com/answers/id-3666057/frequent-bsod-build.html
(it's very possibly something wrong with your ram, as IRQL errors like that usually means it had a problem addressing something in memory)

Sometimes it's only one stick, sometimes it's both, you can test by removing one stick and seeing if it happens, and try the other if it does / doesnt, whatever you can to try and reproduce the crash.
 

BiggestMunchkin

Distinguished
Jun 13, 2012
38
0
18,530


Ah, good shout. I've gone through Gigabyte's website for the drivers that I thought might be at fault, but not thought about manually going through them all. A bit of a pain, but probably a sensible next step.
 
looks like your motherboard driver website stopped updating your drivers.
look here for a new motherboard audio driver from the chipset vendor:
http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=14&PFid=24&Level=4&Conn=3&DownTypeID=3&GetDown=false

It will fix some problem that causes other audio sources to crash and hang GPU drivers.
It is a year newer than the one you have currently installed.

you might want to change your memory dump type to kernel so that proper debug info is saved so it can show problems with plug and play and the USB subsystem.ie provide the kernel memory dump after the next bugchek. file will be c:\windows\memory.dmp

I mention the usb subsystem since you have 3 old Logitech drivers from 2012 installed
you might want to run verifier.exe to check for problems with your other 3rd party drivers.

(some of the old Logitech drivers would respond to usb packets that it does not own, and it results in the real driver from getting its expected packets. This will show up if you run verifier and you change the memory dump to kernel so the internal USB log files are saved in the memory dump)

note: to run verifier start cmd.exe or powershell as an admin then run
verifier.exe /all /standard
google on how to change the memory dump type to kernel.
then make the changes and reboot the system.
Note: make sure you know how to get into safe mode so you can turn off verifier in the case where the system bugchecks during the next boot up.
use verifier.exe /reset to turn off verifier functions. You have to do this after testing or your machine will run slowly until you turn off the functions.
 

BiggestMunchkin

Distinguished
Jun 13, 2012
38
0
18,530
Thanks very much for your helpful suggestions. I've now gone through all the advice from this thread and I'm still encountering the problem, so I figured it was time to come back and report what I've found so far.



I installed that driver, and double checked my other Realtek Audio drivers, and I'm almost certain that the latest version of everything is installed now.

you might want to change your memory dump type to kernel so that proper debug info is saved so it can show problems with plug and play and the USB subsystem.ie provide the kernel memory dump after the next bugchek. file will be c:\windows\memory.dmp

I switched to a Kernel dump. I've found nothing revealing in Whocrashed or BlueScreenView, but perhaps somebody else can make more sense of it (this latest crash I was running audio through a bluetooth speaker instead of my regular desktop speakers, to see if a change there might fix it - apparently not).

I mention the usb subsystem since you have 3 old Logitech drivers from 2012 installed
you might want to run verifier.exe to check for problems with your other 3rd party drivers.

I ran verifier.exe five times, and it didn't pick anything up, which is confusing, because I was sure it was a driver issue. What's more, I ran four passes of memtest86 and that didn't pick up any errors either!

So, yeah, I'm back to having no ideas. Thanks very much for your suggestions so far - any idea where to go from here?
 
the last dump was a minidump with verifier turned off. you should provide a kernel dump with verifier turned on. It will contain the internal error logs and more info.

checksums/tmestamps removed from some files. win32k and win32kbase drivers



 
Solution