If you get a Blue Screen of Death with the stop code SYSTEM_SERVICE_EXCEPTION, there could be many causes, though a bad driver is always a likely culprit. The usual bug check code that goes with a SYSTEM_SERVICE_EXCEPTION is 0x3B. Interestingly, the numeric code has numerous (7!) associations in the Microsoft Error Lookup Tool(opens in new tab), so this one is best researched using the text-based stop code by itself, or in combination with the numeric code. Microsoft’s bug check page(opens in new tab) for this error provides this explanation for its cause: “This indicates that an exception happened while executing a routine that transitions from non-privileged code to privileged code.”
File System Fix For SYSTEM_SERVICE_EXCEPTION
Microsoft also notes on the bug check page for SYSTEM_SERVICE_EXCEPTION that “If a driver that is responsible for the error can be identified, its name is printed on the blue screen…” Indeed, I’ve personally experienced this error with the Windows 10 NTFS file system driver (Ntfs.sys) identified as the culprit. This identification is a mixed blessing, because it does tell you some kind of file system error occurred. That said, one cannot and should not replace OS-level drivers for Windows as one might do for a device driver of some kind.
Such repairs are best left to the DISM and SFC commands. Thus, my first response to the SYSTEM_SERVICE_EXCEPTION stop code after a reboot would be to run these commands in an administrative Command Prompt or PowerShell session:
SFC /scannow
The first command will find and replace any corrupted or missing files in the Windows Component Store (usually C:\Windows\WinSxS). The second command will examine all Windows system files (SFC stands for System File Checker, in fact) and replace any damaged or missing files it identifies. The afore-cited DISM command usually takes 3-5 minutes to complete, and the SFC command can take longer (especially if it makes any repairs). If SFC finds and fixes errors, repeat that same command until you get a clean bill of health in its final follow-up:
Using the Driver Verifier Tool to Fix SYSTEM_SERVICE_EXCEPTION
Windows 10 and Windows 11 both include a built-in driver verification tool named verifier.exe. It resides in the C:\Windows\System32 folder (where Windows keeps many of its admin and repair tools). Drivers are indeed often involved in the SYSTEM_SERVICE_EXCEPTION error because they belong to the class of Windows code elements allowed to access protected system code (along with OS components themselves, of course). Pretty much any device driver can provoke this error, so it’s not uncommon to see it pop up when you install new hardware, or plug in some kind of removable storage device (usually through a USB or Thunderbolt port).
If the previous system repairs (DISM and SFC) don’t dispel the SYSTEM_SERVICE_EXCEPTION BSOD, the Windows Driver Verifier may be able to help you identify the culprit that’s causing this BSOD to occur. This tool comes with a warning: be sure to create a current image backup for your PC before using it, because the verifier checks all device drivers and intentionally causes a BSOD when it finds a driver that cannot be verified or is corrupt or damaged.
The information you seek should show up in the crash dump that gets written when a BSOD occurs. That crash dump will either occupy a file named memory.dmp or minidump.dmp. The former resides in the Windows root, usually C:\Windows. The latter resides in C:\Windows\Minidump. I wholeheartedly recommend using Nir Sofer’s BlueScreenView tool for viewing and inspecting crash dumps. It will happily target either of those crash dump files, and tell you what’s what.
Turning Driver Verifier On
1. Enter “verifier.exe” at an administrative Command Prompt or PowerShell This will open the Driver Verifier Manager program.
2. Click Next and leave the default setting, “Create standard settings” in place.
3. Select “Automatically select all drivers installed on this computer.” If you’d rather focus on a list of drivers by name, click “Select driver names from a list” instead. Either way, click Next to continue.
Unless you want to let your computer take hours testing possibly hundreds of drivers, I have some tips for narrowing this list down and picking suspect drivers from the list.
Tip A: Use DriverStore Explorer to Get Driver Names and Info
A free GitHub project called DriverStore Explorer offers a handy focused software tool for inspecting and managing Windows drivers. I used it on my test system to confirm it had over 200 drivers present, and to clean up enough of the old ones to bring that count down to a “mere” 195. This shows that selecting all drivers can involve a huge number of checks and take a great deal of time. Thus, I tend to concentrate on drivers by name using DriverStore Explorer and focus on drivers by category (e.g. Network adapters, Human Interface Devices, Display adapters, and so forth).
Tip B: Restrict Driver Checks to Suspect Categories or Items, When Possible
Let’s say I just switched from the Lenovo OEM video driver to the Intel DCH video driver on my test PC, after which the SYSTEM_SERVICE_EXCEPTION error started up. DriverStore Explorer tells me the name of that driver is iigd_dch.inf, so that’s the one I want to check for a close match in Driver Verifier Manager’s driver list. Usually igd is shorthand for “Intel graphics driver,” so I choose the item named igdkm64.sys.
4. Click Finish to proceed through your checks. Next you’ll see a warning from Driver Verifier Manager that you must restart your PC to start running its driver checks.
5. Click OK, restart your PC, and you’re on your way! When the system reboots, it may take a little longer to get through the boot-up sequence, as Driver Verifier Manager does its thing. Be patient. As Driver Verifier Manager finds unsigned or suspect drivers it will cause BSODs.
6. Record any bluescreen messages that pop up (it’s handy to snap them with a smartphone), so you can investigate later.
Any BSODs will need subsequent investigation, and should prompt certain actions. In most cases, replacing or upgrading drivers identified in crash dumps after using Driver Verifier will set your system back to rights.
If you find yourself stuck in a boot loop (repeated BSODs that Driver Verifier is causing), you’ll need to boot into Safe Mode (insert link). Then you can access Driver Verifier (type verifier into the Command Prompt or PowerShell). Once you’re into the Driver Verifier Manager UI, choose “Delete existing settings,” then click Finish. After your next restart, your self-induced BSODs will stop.
Beyond the Driver Verifier, It’s Last-Ditch Repairs
If you still can’t get out of the BSOD loop, you may need to take more drastic measures. Restore the OS image you created as a precautionary backup, and you will be back where you started. On the other hand, you could try a 30-minute repair reinstall of WIndows or, if that’s not enough, choose to reset Windows entirely which is the same as a clean install. The last two are obviously maneuvers of last resort.
