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.

Console sign-in versus RDP

1. If RDP is the only trigger, sign in at the physical console and repeat the same account action.
2. If console sign-in works, note that the crash is session-path specific and save the dump before changing policy.
3. Open Settings > System > Remote Desktop on Windows 11, or Settings > System > Remote Desktop on Windows 10, and confirm whether Remote Desktop was recently enabled or changed.

Local account versus domain account

1. Create or use one local administrator account if available.
2. Test the same trigger with one local account and one domain account.
3. Record which account type crashes, and whether it happens at sign-in, sign-out, or both. That note is often more useful than another blind driver reinstall.

Exact policy and session checks for domain-joined systems

1. Open Local Security Policy: press Win + R, type secpol.msc.
2. Review Local Policies > User Rights Assignment for recent changes affecting sign-in paths, especially rights tied to local logon and Remote Desktop use.
3. Open gpedit.msc if local policy is used, or check recent applied Group Policy changes from internal IT if the machine is domain-managed.
4. Check System Properties > Remote and confirm who is allowed to connect through Remote Desktop.
5. If the PC is domain-joined or RDP-heavy and only that path fails, escalate with the dump, policy-change timing, and account-test results instead of making broad security-policy edits.

Should you run SFC, DISM, clean boot, or System Restore?

The article suggests running sfc /scannow before DISM /Online /Cleanup-Image /RestoreHealth, after first noting the likely trigger context. Run SFC first for system file repair, DISM next for component-store repair, then use a clean boot to isolate third-party software. Use System Restore when the first BSOD clearly followed a recent change.

Repair Windows files and the component store

1. Open Command Prompt as administrator.
2. Run sfc /scannow. HashRoot advises this step for system file repair.
3. After SFC finishes, run DISM /Online /Cleanup-Image /RestoreHealth. HashRoot also advises this command for component-store repair.
4. Reboot and retest the original trigger, not a different one.

Use a clean boot the right way

1. Press Win + R, type msconfig, then open System Configuration.
2. On the Services tab, check Hide all Microsoft services, then choose Disable all.
3. Open the Startup tab and disable startup items through Task Manager.
4. Reboot and test the same crash trigger. If the BSOD stops, re-enable items in small groups until the fault returns.

System Restore and the OEM note for Asus PCs

1. Open Control Panel > Recovery > Open System Restore, or enter it from Advanced startup if Windows will not boot normally.
2. Choose a restore point from before the first BSOD.
3. On Asus systems, treat the case like any other OEM case: focus on recent chipset, storage, network, and OEM utility changes rather than assuming an Asus-specific cause.

Still not working?

Stop changing variables once the basics are done and the crash is still reproducible. At that point, the fastest route is a clean handoff with the dump, trigger notes, recent-change history, account-test results, and Driver Verifier outcome, because those pieces let IT or a vendor reproduce the failure without undoing your work.

If that didn’t work, use this escalation ladder

1. If the machine boots only in Safe Mode, copy C:\Windows\Minidump or C:\Windows\MEMORY.DMP off the PC first.
2. If a single driver rollback, SFC, DISM, clean boot, and the security-software test did not change the symptom, stop adding new variables.
3. For home PCs, use System Restore if a clear restore point exists before the first crash.
4. For domain-joined or RDP-used PCs, send internal IT or the software vendor: dump file, Event Viewer time, Reliability Monitor screenshot or notes, exact trigger, local-versus-domain account result, and whether verifier /reset was needed.
5. If Windows remains unbootable after rollback attempts, use recovery options before considering a reset. Preserve the dump first.

Prevention

Keep a simple change log for drivers, OEM tools, security agents, and remote-access changes. This stop code appears very infrequently, so the best prevention step is being able to tie the first BSOD to the exact update, install, or policy push that happened just before it.

Frequently asked questions

What does stop code 0x00000046 mean in Windows?

The code itself identifies a specific bug check value and name, but it does not name the bad driver or policy by itself. The practical takeaway is to capture the dump, note the trigger timing, and sort the case by driver change, security-software change, or session path before repairing anything.

Which drivers can trigger the DEREF_UNKNOWN_LOGON_SESSION bug check?

The stop code does not name a driver family on its own. The best suspects are the drivers changed nearest to the first crash, especially storage, network, graphics, chipset, or OEM packages, because those are easy to confirm or dismiss through Device Manager rollback and dump timing.

How do I use Driver Verifier for a 0x00000046 blue screen?

Run verifier from an elevated Command Prompt, choose Create standard settings, and target recent non-Microsoft or unsigned drivers rather than every driver. Reboot to reproduce the crash, then disable it with verifier /reset from Safe Mode or recovery if the PC starts looping.

Should I run SFC and DISM for stop code 0x00000046?

Yes, after the trigger is documented. Run sfc /scannow first to repair Windows system files, then run DISM /Online /Cleanup-Image /RestoreHealth to repair the component store. If both complete cleanly and the crash remains, move to clean boot or the driver branch.

Is 0x00000046 common on Windows 10 or Windows 11?

No. It appears very infrequently, which is why broad assumptions usually waste time. The same repair logic fits both Windows 10 and Windows 11: preserve the dump, record the trigger, test the nearest recent change first, and only then branch into drivers, security software, or session checks.