0x00000046: Fix It by Trigger, Dump, and Event Clues

0x00000046 (DEREF_UNKNOWN_LOGON_SESSION) usually means Windows dereferenced a logon-session object it can’t track. I sort these crashes by trigger context first, sign-in, screen lock and return, RDP, VPN, or security-agent activity, before I touch drivers or policy. Guessing here can turn a one-off BSOD into repeat boot loops, broken remote access, and hours spent undoing bad rollbacks. This guide maps the symptom to the right branch for drivers, security software, and logon or remote-session policy, with checks that fit Windows 10 and 11.

This guide is part of our Windows BSOD stop codes: full list and fixes series.

Which evidence should you capture first for 0x00000046?

Capture the timeline before you change anything: the exact trigger, the last change, whether Safe Mode works, and what Windows logged around the crash.

Write down the trigger before you touch drivers or apps

1. Write the exact moment of failure: boot, sign-in, sign-out, lock and return, sleep/wake, RDP connect, or random idle.
2. Note the last change before the first BSOD: a driver update, security product install, Windows update, domain policy change, or new remote-access setup.
3. Test whether Safe Mode works: Settings > System > Recovery > Advanced startup on Windows 11, or Settings > Update & Security > Recovery > Advanced startup on Windows 10. (easyprotools.com)

Save the evidence Windows already has

1. Check for dumps in C:\Windows\Minidump and C:\Windows\MEMORY.DMP. Copy them elsewhere before making changes. (Microsoft Learn) (Microsoft Learn)
2. Open Event Viewer: press Win + R, type eventvwr.msc, then review Windows Logs > System around the crash time.
3. Open Reliability Monitor: press Win + R, type perfmon /rel, then record the day the failures began and any install events just before them.
4. Save a short note with: exact stop code text, trigger, account used, whether the machine is domain-joined, and whether the crash happens at the console or only over RDP.

What 0x00000046 will not tell you on its own

The stop code value is 0x00000046 and the bug check is listed as DEREF_UNKNOWN_LOGON_SESSION (per Microsoft support). It shows up very rarely, so the code by itself is too thin to name a bad driver, bad policy, or damaged Windows files. The dump, event timing, and recent-change history do that work. (Microsoft Learn)

According to Bug Check 0x46 – Windows drivers – Microsoft Learn — The bug check value is 0x00000046. (source)

Match the crash context to the next step

Use the crash context as your first filter. The right first move after a sign-out crash differs from the right first move after a new antivirus rollout or a storage-driver update, so the table below keeps the path evidence-first and low-risk.

One-page triage table

Likely causes, ranked by what to check first

Start with the thing that changed nearest to the first crash. In practice, I get the best results from this order: recently changed kernel-mode drivers, recently changed security software with kernel components, Windows file or component-store damage, then session-specific conditions on domain-joined or RDP-used PCs.

Ranked troubleshooting order

• First: a recently changed kernel-mode driver, especially when the BSOD began right after an update or device install.
• Next: security software, endpoint protection, or monitoring tools if the crash began right after their install or update.
• Then: run sfc /scannow to check Windows system files, then run DISM /Online /Cleanup-Image /RestoreHealth to repair the component store if SFC finds corruption or the machine still crashes with no driver lead.
• After that: use a clean boot to strip startup and third-party services out of the test, then compare console sign-in, sign-out, RDP, and domain-account behavior one path at a time.

Keep programmer context separate from repair steps

At kernel level, this bug check points to a session-reference problem in code that runs in kernel mode. For end-user repair, I translate that into a narrower workflow: tie the crash to a trigger, preserve the dump, then test the changed driver, security product, or session path one at a time.

Is 0x00000046 a driver problem or a Windows system file problem?

Start with the driver branch if the first crash followed a driver change, new hardware, or an OEM utility install. Use the Windows file-repair branch first only when the machine crashes with no clear change, Safe Mode still works, or driver rollback does nothing.

If that didn’t work, try the driver branch next

1. Open Device Manager: press Win + X > Device Manager.
2. Find the device tied to the recent change: storage, network, graphics, chipset, or a newly added device.
3. Right-click the device > Properties > Driver. If available, choose Roll Back Driver if the issue began after an update; this is the cleanest first move.
4. If rollback is unavailable, choose Update Driver and install the current package from the PC maker or device maker. Avoid blanket “update everything” passes.
5. If the crash began after an OEM utility install, remove that utility from Settings > Apps > Installed apps on Windows 11, or Settings > Apps > Apps & features on Windows 10, then retest.

How to use Driver Verifier without trapping the PC

1. Open Command Prompt as administrator.
2. Run verifier, choose Create standard settings, then select Automatically select unsigned drivers or manually choose recent non-Microsoft drivers only.
3. Reboot and reproduce the crash. HashRoot recommends enabling Driver Verifier to identify faulty drivers, but do not run it against every driver on a production machine.
4. If the machine enters repeated crashes, boot Safe Mode or Windows Recovery Environment, open Command Prompt, and run verifier /reset. (Microsoft Learn)
5. After disabling Verifier, save the new dump and compare the blamed driver with the recent-change list before making another change.

What if Driver Verifier keeps crashing the PC?

1. Enter recovery: power on, interrupt boot repeatedly until Preparing Automatic Repair appears, then choose Advanced options.
2. Go to Troubleshoot > Advanced options > Startup Settings > Restart, then choose Safe Mode.
3. Open Command Prompt as administrator and run verifier /reset.
4. Reboot normally. If still unbootable, preserve the dump and timing notes first, then use System Restore from Troubleshoot > Advanced options > System Restore.

Can antivirus or endpoint security software cause 0x00000046?

Yes, but only as a context-driven suspect. Treat security software as the first branch only when the BSOD started right after an install, upgrade, policy push, or sensor change, and keep the test temporary: uninstall cleanly, reboot, confirm the result, then rebuild with the vendor’s current package.

Run a clean security-software test

1. Open Settings > Apps > Installed apps on Windows 11, or Settings > Apps > Apps & features on Windows 10.
2. Identify products that install kernel components: antivirus, endpoint protection, device-control tools, and monitoring agents. Focus on products changed nearest to the first crash.
3. Use the product’s normal uninstall path first. If the vendor supplies a cleanup tool, use that vendor path next, then reboot.
4. Retest the original trigger: sign-in, sign-out, boot, or RDP. If the BSOD stops, reinstall the current vendor build or apply the vendor hotfix, then retest immediately.
5. If the machine is domain-managed, record the software name, version, deployment time, and result of the uninstall test for internal IT before the product is redeployed.

What evidence matters here

The useful proof is timing: did the first BSOD begin after the product install or update, and did it stop after a vendor-approved uninstall? That is far stronger than guessing from the code name alone. Any link to identity tools, VPN components, or monitoring agents should stay tied to that sequence.

What if 0x00000046 happens during logon, logout, or Remote Desktop?

Compare session paths instead of assuming policy damage. Test console sign-in versus RDP, test one local account and one domain account, then review Local Security Policy, Group Policy history, and Remote Desktop settings only if the crash follows one path and not the others.