Windows 10: 0x0000003b BSOD - I'm out of ideas!

So just to confirm

1) Uninstall AI Suite
2) No need to uninstall RAM Disk
3) Try Verifier again?

And would you agree a little bizarre that Verifier itself is causing repeatable BSODs? ( At least I can reliably recreate a BSOD now, lol )

 

RAM Disk is up to you if you want to uninstall or not?

- Verifier is meant to cause BSODs irrelevant of the frequency
Depending on the dumps there's an underlying root cause that causes the repeatable crashes, if you could upload them please.

 

Trying to generate logs now. Stuck in BSOD loop and unable to get out of it.

I can get to Safe Mode (Thank God) which is where I'm posting from now.

These steps do not work for me

jaywalker said:


was able to get safe mode running by bringing up an admin console window and entering
bcdedit /set {default} safeboot minimal

turned off verifier
turned off safe mode with
bcdedit /deletevalue {current} safeboot

Rolling back to a Macrium image from 04/04. My bad for not taking an image before I set Verifier again.

 

Those steps might not work due to changes in Window 10 since the day of the post, I'll have a look at it when I have some time.

It looks like each dump is caused by the same driver from Citrix, I don't know what product and/or software you're using but is there a chance there's a software update or could you downgrade the software?

The date of the driver according to Windbg.
Code: 8: kd> lmvm ctxusbm Browse full module list start end module name fffff80e`bc7c0000 fffff80e`bc7e2000 ctxusbm T (no symbols) Loaded symbol image file: ctxusbm.sys Image path: \SystemRoot\system32\DRIVERS\ctxusbm.sys Image name: ctxusbm.sys Browse all global symbols functions data Timestamp: Fri Jan 26 16:49:00 2018 (5A6B4DEC) CheckSum: 000222E4 ImageSize: 00022000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4[/quote]

 

Cheers. Rolling back to v 4.9 Long Term Service Release as had the latest variant

Receiver 4.9 LTSR for Windows - Citrix

I use Citrix for work-related connectivity so kind of need it, I'll also uninstall AI Suite and take another Macrium Image before messing around again! *Think*Redface

 

You mentioned it, so I asked if you could downgrade since I wasn't aware if there's a feature change of bugfix that affected your work *Smile

 

Thanks for your continued support. Not sure what you would like me to try next. For what it's worth, my next steps are these

1) Uninstall AI Suite - DONE
2) Roll back Citrix receiver - DONE
3) Take Macrium full image - DONE
4) Kill the PC with Verifier again - NEXT STEP *Biggrin

I will then attach logs to this Post by editing and await your response.

Thanks again for this, it's a real noodle scratcher but even if we can't resolve or definitively diagnose, I'm sure the methodology will help others.

 

Dumps added. BSOD again, System Restore resolved.

Chris

 

So a System Restore resolved your issue? If so that's great! *Smile

To note; ASUS AI Suite has been known since Windows 7 to cause some issues that causes BSODs. It gave me issues with BSODs on W10 Pro 1709.

 

I think I may have 2 x issues which is perhaps what has confused me!

Since uninstalling AI Suite the PC seems stable. However . . . .

Putting my RAM to 2133MHz (XMP Profile 1) - locked up the PC - so I need to stay at JDEC SPD of 1600MHz for now. Whilst it's a separate issue to this thread of course, I believe that the IMC (Integrated Memory Controller) on my 4930k is not strong enough to drive 64GB (8x8GB) of RAM. That's a separate "overclocking" journey upon which I'm now happier to travel - assuming the software issues have now been resolved.

I'll still await diagnosis of the last dumps I attached though, please guys. The reason for this is that even after uninstalling the software which seems problematic - the Driver Verifier BSOD is BEFORE entering Windows.

My understanding is that the PC should get as far as the shell i.e. desktop before that happens. Is that correct?

Thanks again for providing such an excellent forum, I'm very grateful for the continued input.

 

Sorry for the slight delay, I've been preparing myself for a job application.

Am I correct when I say some storage devices are connected to Asmedia ports? If not I would be surprised to see some Asmedia drivers back in this IRP (I/O Request Packet, communication method to have contact with other drivers and the OS).
Code: 8: kd> !irp ffffc6802cb0c010 1 Irp is active with 8 stacks 9 is current (= 0xffffc6802cb0c320) No Mdl: No System Buffer: Thread ffffc68025df1040: Irp is completed. Flags = 00000000 ThreadListEntry.Flink = ffffc6802cb0c030 ThreadListEntry.Blink = ffffc6802cb0c030 IoStatus.Status = c00000bb IoStatus.Information = 00000000 RequestorMode = 00000000 Cancel = 00 CancelIrql = 0 ApcEnvironment = 00 UserIosb = 00000000 UserEvent = 00000000 Overlay.AsynchronousParameters.UserApcRoutine = 00000000 Overlay.AsynchronousParameters.UserApcContext = 00000000 Overlay.AllocationSize = 00000000 - 00000000 CancelRoutine = 00000000 UserBuffer = 00000000 &Tail.Overlay.DeviceQueueEntry = ffffc6802cb0c088 Tail.Overlay.Thread = ffffc68025df1040 Tail.Overlay.AuxiliaryBuffer = 00000000 Tail.Overlay.ListEntry.Flink = 00000000 Tail.Overlay.ListEntry.Blink = 00000000 Tail.Overlay.CurrentStackLocation = ffffc6802cb0c320 Tail.Overlay.OriginalFileObject = 00000000 Tail.Apc = 00000000 Tail.CompletionKey = 00000000 cmd flg cl Device File Completion-Context [N/A(0), N/A(0)] 0 2 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 ffffffffc00000bb [N/A(0), N/A(0)] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [N/A(0), N/A(0)] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [N/A(0), N/A(0)] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [N/A(0), N/A(0)] 0 10 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [IRP_MJ_PNP(1b), IRP_MN_START_DEVICE(0)] 0 12 ffffc6802ca02880 00000000 fffff803439cd010-ffffaf8c7d9c41f0 *** WARNING: Unable to verify timestamp for asmtxhci.sys *** ERROR: Module load completed but symbols could not be loaded for asmtxhci.sys \Driver\asmtxhci nt!ViFilterGenericCompletionRoutine Args: 00000000 00000000 00000000 00000000 [IRP_MJ_PNP(1b), IRP_MN_START_DEVICE(0)] 0 10 ffffc6802cb00ae0 00000000 fffff803439cd010-ffffaf8c7d9c45c0 *** WARNING: Unable to verify timestamp for asmthub3.sys *** ERROR: Module load completed but symbols could not be loaded for asmthub3.sys *** WARNING: Unable to verify timestamp for ctxusbm.sys *** ERROR: Module load completed but symbols could not be loaded for ctxusbm.sys \Driver\asmthub3 nt!ViFilterGenericCompletionRoutine Args: 00000000 00000000 00000000 00000000 [IRP_MJ_PNP(1b), IRP_MN_START_DEVICE(0)] 0 10 ffffc6802cb049e0 00000000 fffff80343302060-ffffc6802cb88fc0 \DRIVER\VERIFIER_FILTER nt!PnpDeviceCompletionRoutine Args: 00000000 00000000 00000000 00000000 Irp Extension present at 0xffffc6802cb0c320:[/quote]

No, the boot process exists of various phases.
Driver verifier is loaded as soon as ntoskrnl is called by Winload which is called after the boot manager is finished. Ntoskrnl has 2 phases of initialization. The first phase loads all BSOD messages, initializes driver verifier, creates some processes and does a few other things. The second phase ensures driver verifier is working and initializes components like the system time and drivers. Then smss.exe loads autochkdsk, registry hives, some dll's and some executables. Then winlogon.exe registers the user and userinit.exe runs the final scripts for both the user and the machine.

The login screen is 1 of the last steps in the boot process whilst driver verifier and all the drivers are loaded long before that. This is the reason why some users cannot log back in when driver verifier is enabled, some boot drivers are causing trouble in those situations.