Question 0x0000009f BSOD every few minutes ?

[Meyerka]

Hello,

Yesterday i plugged in a new steelseries arctis nova 7 headset into my pc (coming from turtle beach). At first the pc didn't seem to recognize it but after putting it in a different usb socket it recognized the headset and worked for a bit..
Thats when the blue screens started and keeps repeating every few minutes.
I'm not sure what to do about it as i dont have much time inbetween blue screens.

Any help is very much appreciated and thank you in advance!

Here's the dumpfile:
https://drive.google.com/file/d/1ySasntLCQ89BT3QKvxPWqvMiBjVQQP06/view?usp=sharing

PC Specs
Mobo: Gigabyte B850 Eagle
CPU: Ryzen 7 9700X
GPU: XFX Speedster Merc 7800 XT
RAM: 32GB DDR5 - 6000mhz
PSU: 750w Gold

 

[johnbl]

I just went through all the 4 dumps from tonight.
Results:
2x AtihdWT6.sys
1x HDAudBus.sys
1x storahci.sys

Looks like these are more symptoms than causes since there's 1 outlier here? Could it be some weird power setting going ham? Perhaps cause F3a bios version? Or some power setting in the bios?
Still weird that the system was stable for quite some months until a headset plugin.

I was trying to find the owner of the file AtihdWT6.sys
it is using a old naming convention. there will be a service that talks to this device. if the service does not match the build version of the driver then the power request will not be correct.

I would look for the service and disable it, or disable it in the bios hardware support or use microsoft autoruns64.exe and disable the driver and reboot to see if your system will run longer before bugcheck

naming of the driver:
ATI Technologies was a Canadian company acquired by AMD in 2006. Amd rebranded everything as AMD so I am not sure where the ati driver came from.

 

[Meyerka]

I was trying to find the owner of the file AtihdWT6.sys
it is using a old naming convention. there will be a service that talks to this device. if the service does not match the build version of the driver then the power request will not be correct.

I would look for the service and disable it, or disable it in the bios hardware support or use microsoft autoruns64.exe and disable the driver and reboot to see if your system will run longer before bugcheck

Apparently the owner is the following:
File Description: AMD HDMI Audio Driver
Provider: Advanced Micro Devices, Inc. (AMD)
Digital Signature:
Officially signed by AMD using Microsoft’s WHQL process (in WHQL-certified driver packages)

• Comes bundled with the Adrenalin installer (e.g., AMD Software: Adrenalin Edition)
• The driver is referenced via atihdwt6.inf — that's the driver installation script used by Windows during setup

 

[johnbl]

Apparently the owner is the following:
File Description: AMD HDMI Audio Driver
Provider: Advanced Micro Devices, Inc. (AMD)
Digital Signature:
Officially signed by AMD using Microsoft’s WHQL process (in WHQL-certified driver packages)

• Comes bundled with the Adrenalin installer (e.g., AMD Software: Adrenalin Edition)
• The driver is referenced via atihdwt6.inf — that's the driver installation script used by Windows during setup

so this is a HDMI audio driver for a video card? (add on card)
not the HDMI audio driver for the amd CPU motherboard hdmi port. Not the motherboard HDMI sound driver for the motherboard built in sound device?

i would make sure the gpu sound support service was updated when you reinstalled the gpu + hd audio.
(I would disable the service to see if you still bugcheck, just to figure out if it is the cause of the timeout)

 

[Meyerka]

so this is a HDMI audio driver for a video card? (add on card)
not the HDMI audio driver for the amd CPU motherboard hdmi port. Not the motherboard HDMI sound driver for the motherboard built in sound device?

Correct.
Looks like all 3 audio related ones were part of the GPU hdmi audio.
After using DDU to remove all audio and gpu drivers, the next bsod was the storage one, storahci.sys (Thank god for time stamps)
I got this one during a new installation of the gpu drivers.
After this i let it sit idle for a bit and it bsod'd again but i cant grab the file atm.
After reboot, my internet didn't work.. The reboot after i couldnt zip the file.

Unfortunately the pc is now off again ( Gf's PC, im not close to it) so hopefully i can grab the newest dump tommorow.
Currently the pc is still sitting without audio and gpu drivers.

 

[johnbl]

so this is a HDMI audio driver for a video card? (add on card)
not the HDMI audio driver for the amd CPU motherboard hdmi port. Not the motherboard HDMI sound driver for the motherboard built in sound device?

i would make sure the gpu sound support service was updated when you reinstalled the gpu + hd audio.
(I would disable the service to see if you still bugcheck, just to figure out if it is the cause of the timeout)

guess the program service might be loaded in the windows startup. if so you could remove it from the startup programs.

 

[Meyerka]

guess the program service might be loaded in the windows startup. if so you could remove it from the startup programs.

So i'm just spitballing with chatgpt ( i like talking over my thoughts) and i'd like to run this idea by you as im not very educated in this matter:
Before deleting the gpu and audio drivers, the HDMI audio kept getting the blame.. After removing those (Kinda need the newest dumpfile to verify as i dont like a singular file) We see a storage driver at fault. Could it be that driver is just the next weakest one in the chain after hdmi drivers? Both apparently rely on low power state transitions.
Multiple devices seem to struggle with power control so this would point towards the bios, no?

 

[johnbl]

So i'm just spitballing with chatgpt ( i like talking over my thoughts) and i'd like to run this idea by you as im not very educated in this matter:
Before deleting the gpu and audio drivers, the HDMI audio kept getting the blame.. After removing those (Kinda need the newest dumpfile to verify as i dont like a singular file) We see a storage driver at fault. Could it be that driver is just the next weakest one in the chain after hdmi drivers? Both apparently rely on low power state transitions.
Multiple devices seem to struggle with power control so this would point towards the bios, no?

windows made changes too low power sleep states. When ever they introduce more low power states, it then exposes a bunch of driver bugs. I keep seeing issues in the kernel dump files where windows asks a driver if it supports a low power state and it says yes, then windows tells it go do the low power state but the code to wake up was never implemented. Ends up screwing up a bunch of stuff, that is waiting for its turn to act on the signals.

All, you can do is update drivers and hope for bug fixes. You can also remove devices in device manager control panel and let plug and play reinstall them. This can work even if the driver is bad because it can change the order of the devices that get the signals. even updating the bios or making a change in bios might fix problems since it forces the bios to scan hardware again and rebuild the database of settings used by the bios to windows plug and play so it knows what hardware resources are free. for example, DMA devices are very limited and there might be conflicts. I often find that it is helpful to disable any sound device that does not have a speaker connected to it.
(mainly since the old realtek motherboard sound driver responding to DMA request from other sound drivers and would corrupt buffers of other sound drivers mainly of nvidia GPU sound drivers) problems like this were hard to detect but went away when you disabled the motherboard sound hardware, (After years of seeing this problem realtek fixed their driver)

it used to be that many of these subsystems were pretty isolated but now everything is routed to the pci/e bus since it is so fast. one bug and the whole system starts to have problems.

kernel memory dumps provide the internal log files and debug info on plug and play, system locks and the usb subsystem.

yes, this can be a bug in your bios acpi interface.
usually what happens is they update the bios and new functions get enabled, windows power management tells the hardware to use the new functions and your system breaks due to old/bad drivers. Most often it happens when there is a major version update. IE windows 7 to windows 8 was really bad for hitting this type of bug.

currently, audio devices are suspect. Changes to specification now allow a sleeping headphone, wake up then tell a sleeping usb port to wake up and wake up the hub or sub hub that it is on. Often you have to update a headset or microphone firmware, update the bios, and sometimes update on board usb firmware for it to work correctly. I have seen some headsets that after the firmware is updated, could not wake up a hub that was connected to another hub but could wake if it was connected directly to the motherboard usb hub.

some bluetooth radios in laptops are connected to usb hubs internally then the hub is connected to the PCI/e bus. there have been a lot of issues with this after recent power updates. (driver problems)

 

[Meyerka]

windows made changes too low power sleep states. When ever they introduce more low power states, it then exposes a bunch of driver bugs. I keep seeing issues in the kernel dump files where windows asks a driver if it supports a low power state and it says yes, then windows tells it go do the low power state but the code to wake up was never implemented. Ends up screwing up a bunch of stuff, that is waiting for its turn to act on the signals.

All, you can do is update drivers and hope for bug fixes. You can also remove devices in device manager control panel and let plug and play reinstall them. This can work even if the driver is bad because it can change the order of the devices that get the signals. even updating the bios or making a change in bios might fix problems since it forces the bios to scan hardware again and rebuild the database of settings used by the bios to windows plug and play so it knows what hardware resources are free. for example, DMA devices are very limited and there might be conflicts. I often find that it is helpful to disable any sound device that does not have a speaker connected to it.
(mainly since the old realtek motherboard sound driver responding to DMA request from other sound drivers and would corrupt buffers of other sound drivers mainly of nvidia GPU sound drivers) problems like this were hard to detect but went away when you disabled the motherboard sound hardware, (After years of seeing this problem realtek fixed their driver)

it used to be that many of these subsystems were pretty isolated but now everything is routed to the pci/e bus since it is so fast. one bug and the whole system starts to have problems.

kernel memory dumps provide the internal log files and debug info on plug and play, system locks and the usb subsystem.

yes, this can be a bug in your bios acpi interface.
usually what happens is they update the bios and new functions get enabled, windows power management tells the hardware to use the new functions and your system breaks due to old/bad drivers. Most often it happens when there is a major version update. IE windows 7 to windows 8 was really bad for hitting this type of bug.

currently, audio devices are suspect. Changes to specification now allow a sleeping headphone, wake up then tell a sleeping usb port to wake up and wake up the hub or sub hub that it is on. Often you have to update a headset or microphone firmware, update the bios, and sometimes update on board usb firmware for it to work correctly. I have seen some headsets that after the firmware is updated, could not wake up a hub that was connected to another hub but could wake if it was connected directly to the motherboard usb hub.

some bluetooth radios in laptops are connected to usb hubs internally then the hub is connected to the PCI/e bus. there have been a lot of issues with this after recent power updates. (driver problems)

Very insightful, thank you! Way more to it than i expected. Sounds like quite the nightmare to go through all this and pinpoint the problem.

All this being said, what would your next steps be?
It's currently sitting with no gpu and audio drivers.
There is 1 usb entry that keeps coming back with an error even after havibg it uninstalled a few times now. Perhaps a lead here?

 

[johnbl]

I looked at the other bugchecks in the last batch.
The oldest one had verifer turned on and was
was caused by a audio device with this service:
AtiHDAudioService

all of the bugchecks were with the audio device or with the interface to the audio device. I did not see any in the storage driver for this last batch of dumps.

verifier provides more info, but you would need verifier and a kernel dump to read the logs.



10: kd> !DevNode ffff808dd6af4bd0
DevNode 0xffff808dd6af4bd0 for PDO 0xffff808dd051bb90
Parent 0xffff808dc750e960 Sibling 0000000000 Child 0000000000
InterfaceType 0 Bus Number 0
InstancePath is "HDAUDIO\FUNC_01&VEN_1002&DEV_AA01&SUBSYS_00AA0100&REV_1008\5&28a47e64&0&0001"
ServiceName is "AtiHDAudioService"
State = Unknown State (0x0)
Previous State = Unknown State (0x0)
Flags (0000000000)

 

[johnbl]

I would go into bios, change anything and change it back. save the results, reboot into windows, go into control panel device manager
find audio devices and delete them and rescan hardware to get plug and play to put them back.

if you do not bugcheck, I would then look at the list of services and disable this:
ServiceName is "AtiHDAudioService"

and reboot, then see if you still bugcheck. most of the bugchecks were at 2 min 30 seconds or so.
the verifier bugcheck took longer 6 mins.

I am thinking two devices are responding to one device request.
most often a device breaks itself but it can be the victim of another device. generally the device that has the bigger buffer wins and does not crash.

 

[Meyerka]

I would go into bios, change anything and change it back. save the results, reboot into windows, go into control panel device manager
find audio devices and delete them and rescan hardware to get plug and play to put them back.

if you do not bugcheck, I would then look at the list of services and disable this:
ServiceName is "AtiHDAudioService"

and reboot, then see if you still bugcheck. most of the bugchecks were at 2 min 30 seconds or so.
the verifier bugcheck took longer 6 mins.

I am thinking two devices are responding to one device request.
most often a device breaks itself but it can be the victim of another device. generally the device that has the bigger buffer wins and does not crash.

And if this doesn't work?
I'm just wondering, i personally like getting to the bottom of this but the gf doesn't have this sort of patience.. Would a clean windows install from usb fix this problem?
Or would it bsod during installation cause of its current problems?

 

[johnbl]

when I look VEN_1002&DEV_AA01
vendor =1002 device =aa01
it comes up as an old ati gpu from 2007
https://devicehunt.com/view/type/pci/vendor/1002/device/AA01

what is it actually?
maybe plug and play made a mistake and installed the wrong driver? Malware hiding as a old driver (with a new date?)

 

[johnbl]

yes a wipe of the system might fix the problem. if you update, apply the update and the microsoft updates and see if it is stable before applying any third party updates.

 

[Meyerka]

when I look VEN_1002&DEV_AA01
vendor =1002 device =aa01
it comes up as an old ati gpu from 2007
https://devicehunt.com/view/type/pci/vendor/1002/device/AA01

what is it actually?
maybe plug and play made a mistake and installed the wrong driver? Malware hiding as a old driver (with a new date?)

Good catch! I have no clue..
Could it have something to do with the state of the system, I.E. it sitting with no audio and gpu drivers after ddu?

 

[Meyerka]

yes a wipe of the system might fix the problem. if you update, apply the update and the microsoft updates and see if it is stable before applying any third party updates.

What are you referring to with "if you update, apply the update" ?

I'm down to try a few more things but there's a good chance we'll go down the reinstall route as it's a young system with not much on there anyway.
Should get rid of the weird drivers as well.

After that I'll, as you said, make sure it doesn't crash before doing anything else.
Perhaps update the bios as well.

 

[johnbl]

What are you referring to with "if you update, apply the update" ?

I'm down to try a few more things but there's a good chance we'll go down the reinstall route as it's a young system with not much on there anyway.
Should get rid of the weird drivers as well.

After that I'll, as you said, make sure it doesn't crash before doing anything else.
Perhaps update the bios as well.

ie apply a updated version of windows install, then apply windows updates only and see if the system is stable before you apply any third party updates from another source.

ie install windows, run window update,reboot, run windows update until no updates remain. Then install windows optional updates and see if the system is stable.

 

[johnbl]

ie apply a updated version of windows install, then apply windows updates only and see if the system is stable before you apply any third party updates from another source.

ie install windows, run window update,reboot, run windows update until no updates remain. Then install windows optional updates and see if the system is stable.

oh, i thought you updated the bios already. I did not see your version listed, i thought it was current.

 

[Meyerka]

oh, i thought you updated the bios already. I did not see your version listed, i thought it was current.

That's what i assumed since i installed the newest one a few months ago but i saw they released a new version in march.
I've been reluctant to update the bios due to system instability but i now know i should be good to update it if i don't do it through windows.

 

[johnbl]

That's what i assumed since i installed the newest one a few months ago but i saw they released a new version in march.
I've been reluctant to update the bios due to system instability but i now know i should be good to update it if i don't do it through windows.

yes, update it. if they made a bug often they will not tell you and they will just fix it and put out the new version.
also, there can be various tech spec updates that get included in the changes. that is why you have to update the bios then install the motherboard driver updates that will match the changes in bios.

 

[Meyerka]

So, the system runs stable now after doing the following:
- Updated the bios, logged in, system bsod.
- New win11 instal
- Ran all windows updates
- Installed chipset and gpu drivers from the amd website
- Installed steelseries GG and connected the headset in a different port than we used before.

Waited 10 minutes inbetween all steps to see if it ran stable.
The system has been running for over 2 hours now without a BSOD.

There's one error in universal serial bus controllers both before and after the chipset driver instalation.
At this point im guessing its a hardware fault on Port_#0013.Hub_#0004.
Perhaps this is the thing that set it all off as when we plugged in the headset, the pc didn't recognize the headset until after we switched usb port.

We know which port it is so we'll be avoiding that one as we're not ready to go down another rabbit hole as the system runs stable now.

Thank you COLGeek and johnbl for helping and sticking with me.
Unfortunately we didn't get to the bottom of it but atleast it's fixed (for now, knock on wood)

 

[COLGeek]

I suspect the new install of Windows and the BIOS update made things work better.

Good job and good luck.