BSoD 0x3B - system doesn't create dump files

[MrPepka]

As for the problem with not saving memory dumps, as I mentioned, the reason was unloaded drivers for handling memory dumps. These drivers overnight suddenly began to load into itself and the problem disappeared by itself

 

[MrPepka]

I return to the topic. I reported the problem to Gigabyte, but they sold me out saying that it works and that I would reinstall the driver and then check it on a fresh installation of Windows. Well, I checked both solutions and they gave me nothing, so I decided to delve into the case and collect evidence for my application. So I started Driver Verifier with all standard settings and 2 additional (force pending i / o request and irp logging). I first enabled it for the gdrv2.sys driver (only for this driver). It did nothing (the blue screen was still there and no new clue appeared). Then I turned it on for drivers gdrv2.sys and wdf01000.sys (I turned on 3 additional option Port / miniport interface checking). Here, after turning on the AORUS Engine, the system hung (the circle next to the cursor hung, and then the cursor disappeared and the system remained in freezing). I did something else. I enabled Driver Verifier (the same options as usual, but without this Port / miniport interface checking) for the gdrv2.sys and ntoskrnl.exe drivers (yes, for the Gigabyte driver and the system kernel). At that time, I had a blue screen one minute after starting the system (first error code 0x1A, then 0x7E). Blue screen 0x1A I had how it started the whole APP Center from Gigabyte, but I managed to disable the launch of the APP Center at system startup, and right after I did it a minute after starting the system, the blue screen was still displaying, but with error code 0x7E. I started the analysis of memory dump and during the analysis it turned out that ... Logitech drivers are to blame despite the fact that I did not enable Driver Verifier for them! I turned on Driver Verifier for the Wdf01000 and ntoskrnl.exe drivers to verify the connection of the gdrv2.sys driver to the system kernel or WDF driver (I wanted to check if there was a code error somewhere), and I received completely different results than expected. So it looks like the Gigabyte driver conflicts with the Logitech drivers, but maybe it's a false alarm, and I'm still going astray?
I attach crash dumps

 

[x BlueRobot]

Please remove the Gigabyte software again, it's bloatware and was causing you problems before.

I would certainly consider updating your Logitech drivers as well:

12: kd> lmvm logi_joy_vir_hid
Browse full module list
start end module name
fffff800`7f410000 fffff800`7f419000 logi_joy_vir_hid T (no symbols)
Loaded symbol image file: logi_joy_vir_hid.sys
Image path: \SystemRoot\system32\drivers\logi_joy_vir_hid.sys
Image name: logi_joy_vir_hid.sys
Browse all global symbols functions data
Timestamp:  Mon Apr 2 18:02:23 2018 (5AC2D29F)
CheckSum: 0000A7EF
ImageSize: 00009000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Information from resource tables:

Looks like the same issue we discussed previously in the BSOD Academy.

 

[MrPepka]

Thanks for the answer. Well, apparently I have no choice. But then I have a question. Since in Driver Verifier I selected for verification the driver from Gigabyte (gdrv2.sys) and the kernel driver (ntoskrnl.exe), how did it happen that completely other drivers were broken that were not verified?

 

[x BlueRobot]

Driver Verifier will only perform specific checks, it's likely the reason why the driver failed may not part of DV's checks and therefore it defaulted to the bugcheck shown.