BSOD on Windows 11 21H2

[DrJedikiah]

I got BSOD while waking up from sleep. Bugcheck code is WDF_VIOLATION and parameter is 0x4

I'm using the latest release version 1.21.442.0

This is the stack

[Benjamin Höglinger-Stelzer]

Do you have a minudump or kernel memory dump I could analyse? If you need a private file transfer method, I can provide one.

Cheers

[DrJedikiah]

I have minidump and also a full memory dump but it's too big for me to upload.
(edited link) I doubt there's sensitive info in there, so I just uploaded here and I can delete it later just incase

[Benjamin Höglinger-Stelzer]

I have minidump and also a full memory dump but it's too big for me to upload. https://gofile.io/d/Q77Gjl I doubt there's sensitive info in there, so I just uploaded here and I can delete it later just incase

That link doesn't work. Compress the kernel memory dump which will shrink it down to one third its size and upload it here: https://files.nefarius.at/

No need to share the resulting link, only I will see it on the server, tell me when upload is done. It indeed does contain sensitive information so no public sharing pls 😉

[DrJedikiah]

Uploaded the minidump. Full dump is still too big and because I almost never shutdown my pc, I have no clue what info might be inside, no offense. There's an unknown function in the stack, I hope you can pinpoint it with the pdbs.

[Benjamin Höglinger-Stelzer]

Uploaded the minidump. Full dump is still too big and because I almost never shutdown my pc, I have no clue what info might be inside, no offense. There's an unknown function in the stack, I hope you can pinpoint it with the pdbs.

All kernel memory at the point of the crash is in there, which means potential passwords, encryption keys, ...

[sb0bs]

I've also experienced a BSOD with the identical stack trace.

After spending some time analysing my memory dump I've mapped it to the EvtWdfIoPendingNotificationQueueState callback, which receives an invalid this pointer to a PDO object resulting in _UsbInterruptOutBufferQueue member being NULL.

For me it looks like the PDO object has been destroyed after being "Unplugged" but the _PendingNotificationRequests still exists since its parent is the FDO object. When Windows wakes up it restarts the _PendingNotificationRequests queue and calls the callback with an pointer to a deleted object. I could be wrong as I am not familiar with driver development, literally knew nothing about it until yesterday.

Is there any reason why the code below uses ParentDevice instead of this->_PdoDevice?

	status = WdfIoQueueCreate(
			ParentDevice,
			&notificationsQueueConfig,
			WDF_NO_OBJECT_ATTRIBUTES,
			&this->_PendingNotificationRequests
		);

[nordeep]

Have the same issue with latest release.
OS: Windows 11 21H2

[nickp85]

I believe I also experienced this. It happened after my DS4 went to sleep due to inactivity. Using Moonlight to stream from Sunshine to an Apple TV 4K. Windows 11 22H2 here. After powering the controller back on, it was not detected again. Tried restarting moonlight and sunshine but no luck then eventually the BSOD and after reboot it's working again

[Jeff Billimek]

I'm experiencing the same issue (Windows 11 is BSODing/rebooting after waking from sleep) with the same error code of WDF_VIOLATION (10d).

This happens consistently anytime I use sunshine from a moonlight client using PS5 controller via ViGEmBus on the sunshine host system. The symptoms are always whenever the system enters a sleep state and is woken-up, the same WDF_VIOLATION BSOD occurs and subsequent reboot.

Analyzing the minidumps all show items suggesting that ViGEmBus is involved,

STACK_TEXT:  
ffffbe8c`d3614238 fffff807`0ee05b50     : 00000000`0000010d 00000000`00000004 00000000`00000000 fffff807`1e82b226 : nt!KeBugCheckEx
ffffbe8c`d3614240 fffff807`0ee05bdc     : fffff807`1e82b226 ffffe20f`ad215b00 fffff807`1e842288 fffff807`1e836979 : Wdf01000!FxVerifierBugCheckWorker+0x24 [minkernel\wdf\framework\shared\object\fxverifierbugcheck.cpp @ 87] 
ffffbe8c`d3614280 fffff807`0edd65e7     : 00000000`00000000 fffff807`1e82d989 00000000`00000000 ffffe20f`ae15dd50 : Wdf01000!FxVerifierNullBugCheck+0x44 [minkernel\wdf\framework\shared\object\fxverifierbugcheck.cpp @ 122] 
ffffbe8c`d36142c0 fffff807`1e82b226     : 00001df0`54d9c548 ffffe20f`910ccba0 fffff807`1e842288 fffff807`1e83e718 : Wdf01000!imp_WdfObjectGetTypedContextWorker+0xdd67 [minkernel\wdf\framework\shared\object\handleapi.cpp @ 716] 
ffffbe8c`d3614310 00001df0`54d9c548     : ffffe20f`910ccba0 fffff807`1e842288 fffff807`1e83e718 00000000`00000000 : ViGEmBus+0xb226
ffffbe8c`d3614318 ffffe20f`910ccba0     : fffff807`1e842288 fffff807`1e83e718 00000000`00000000 ffff9500`995d1180 : 0x00001df0`54d9c548
ffffbe8c`d3614320 fffff807`1e842288     : fffff807`1e83e718 00000000`00000000 ffff9500`995d1180 00001df0`5b66c408 : 0xffffe20f`910ccba0
ffffbe8c`d3614328 fffff807`1e83e718     : 00000000`00000000 ffff9500`995d1180 00001df0`5b66c408 fffff807`1e8260ac : ViGEmBus+0x22288
ffffbe8c`d3614330 00000000`00000000     : ffff9500`995d1180 00001df0`5b66c408 fffff807`1e8260ac ffffe20f`ad215b00 : ViGEmBus+0x1e718

SYMBOL_NAME:  ViGEmBus+b226
MODULE_NAME: ViGEmBus
IMAGE_NAME:  ViGEmBus.sys
STACK_COMMAND:  .cxr; .ecxr ; kb
BUCKET_ID_FUNC_OFFSET:  b226
FAILURE_BUCKET_ID:  0x10D_4_ViGEmBus!unknown_function
OSPLATFORM_TYPE:  x64
OSNAME:  Windows 10

[chestermw]

Hi all,
I raised a discussion earlier and it seems like my issue is somewhat related to this. Mine crashes when resuming from hibernate (rebooting the whole system) losing my hibernated apps.

I'm on w11 22H2

#171

[chestermw]

For those experiencing this issue with Sunshine + Moonlight....
It seems I have found a workaround.

The idea of the fix was to restart sunshine services in the background just before the system goes into sleep/hibernate.

Below is a file that you can import into Task Scheduler.
restart_sunshine.zip

Hope this helps anyone who is experiencing the same issue.

[Jeff Billimek]

Hope this helps anyone who is experiencing the same issue.

Can confirm that this is workaround has the intended affect. Thank you @chestermw!