⚠ CrashDecoder

0x00000154 UNEXPECTED_STORE_EXCEPTION

Windows compresses memory pages rather than writing them straight to disk, keeping them in a compressed store in RAM. When the component managing that store hits an exception it did not anticipate, it stops the machine. The name suggests memory, and memory is involved - but in practice the drive underneath is implicated at least as often, and that is worth knowing before you buy anything.

Updated 2026-07-27Stop errorAlso written: 0x154, UNEXPECTED STORE EXCEPTION, unexpected_store_exception

What you are looking at

:(

Your PC ran into a problem and needs to restart.

Stop code: UNEXPECTED_STORE_EXCEPTION

In Event Viewer the matching entries look like this:

Log Name:      System
Source:        BugCheck
Event ID:      1001
Level:         Error

The computer has rebooted from a bugcheck.  The bugcheck was: 0x00000154 (0xffffc80a1e2b4000, 0xffffd48f3a1c25a0, 0x0000000000000000, 0x0000000000000000).

What the error actually means

Modern Windows does not simply page memory out to disk when it runs short. It first tries compressing pages and keeping them in RAM, on the reasoning that decompressing from memory is far faster than reading back from storage. The component that manages this is the store manager.

That store still interacts with the disk. Compressed pages can be written out, and the store is closely tied to the page file. So the store manager sits at the junction between memory and storage, and it can be broken from either side.

When it encounters an exception it has no handler for - a page that will not decompress, data that comes back wrong, an I/O failure it cannot recover from - it bugchecks. The name points at the store, but the store is usually the messenger.

Reading the parameters

The parameters here are largely opaque outside a debugger, which is unusual and slightly unhelpful. The diagnosis rests on the surrounding evidence rather than the values.

ParameterWhat it holds
1A pointer to the store context or data manager. Only meaningful in a debugger.
2Exception information. Occasionally distinguishes an I/O failure from a data-integrity failure, though the values are not publicly documented in detail.
3Reserved.
4Reserved.

What actually triggers it

Two sources disagree here, and you should know that

Microsoft's own reference for this bugcheck characterises it as a typical software driver bug and states it is not likely to be caused by a hardware problem. Practical experience points the other way: 0x154 has a long and well-observed association with failing storage devices, particularly on laptops with dying drives.

Both can be true. The store manager sits between memory and disk, so a driver in that path and a drive returning bad data produce the same exception. The ordering below reflects what most often turns out to be responsible on consumer machines - but the triage steps are designed to tell you which case you actually have rather than to assume. Check the drive because it is quick and conclusive, not because the answer is predetermined.

Ordered by what tends to be responsible in practice:

CauseHow oftenDetail
Failing storage driveCommonThe leading cause in practice. The store interacts with the page file and with disk I/O, so a drive that returns errors or stalls on reads produces exceptions the store manager cannot handle. Historically this code was strongly associated with dying laptop hard drives, and it remains the first thing to check.
Failing RAMCommonCompressed pages live in memory. A bad cell corrupts a compressed page so it will not decompress correctly, and the store hits an exception decoding data that should have been valid.
Storage drivers and filter driversOccasionalAnti-virus products that scan file I/O sit directly in this path. So do third-party storage drivers and disk encryption software.
A corrupt page fileOccasionalThe store and the page file are tightly coupled. A page file damaged by an unclean shutdown or a storage fault feeds bad data straight back in.
Display driversRareReported often enough to mention, though the mechanism is indirect. If everything else is clean and the crashes correlate with graphics activity, a clean display driver reinstall is a reasonable late step.
Corrupt system filesRareCheap to rule out, rarely the answer.

Narrowing it down

Check the drive first. It is the highest-yield test on this particular bugcheck and it takes twenty minutes.

Read SMART data before anything else

Install CrystalDiskInfo and look at the system drive. On a hard drive, check reallocated sector count, pending sector count and uncorrectable sector count. On an SSD, check percentage used, available spare and media errors.

What it tells you

Anything other than a clean bill of health makes storage the prime suspect and makes every software fix below temporary. A perfectly healthy drive moves attention to memory.

Check the file system

Run a read-only scan first, which is safe on a live system:

chkdsk C: /scan

If it reports problems, schedule a full repair with chkdsk C: /f /r - but image the drive first if you suspect it is failing and the data matters.

What it tells you

File system errors on a drive that also reports SMART problems is a failing drive, not a software issue. Errors on a healthy drive usually trace back to an unclean shutdown.

Test memory

MemTest86 from USB, four passes minimum, with XMP or EXPO disabled.

What it tells you

Errors are conclusive. A clean run at stock, with a healthy drive, shifts attention to drivers and the page file.

Try disabling memory compression - as a test only

From an administrator PowerShell window:

Disable-MMAgent -MemoryCompression

Reboot, then run normally for a few days. To reverse it:

Enable-MMAgent -MemoryCompression
What it tells you

If the crashes stop, that confirms the store is where the fault surfaces - it does not tell you what is corrupting it. Treat a successful result as a diagnostic signal and keep investigating the drive and memory. Leaving compression off permanently increases disk paging and hides an underlying fault that will resurface elsewhere.

Fixes, cheapest first

Storage first, then memory, then everything else.

  1. Check and repair the drive

    Effort: 30 minutes to hours · Risk: Low

    Run chkdsk C: /f /r on the system volume. Update the drive's firmware if the vendor has a newer release - SSD firmware bugs affecting data integrity under specific conditions are real and are fixed this way.

    Watch out

    If SMART data already indicates a failing drive, back up before running /r. A surface scan on a dying disk can accelerate the failure.

  2. Rebuild the page file

    Effort: 15 minutes · Risk: Low

    Because the store and the page file are coupled, a corrupt page file is directly implicated.

    1. System Properties, Advanced, Performance Settings, Advanced, Virtual memory, Change.
    2. Clear Automatically manage, select No paging file, apply, and reboot.
    3. Return to the same screen, set System managed size, apply, and reboot again.

  3. Test and stabilise memory

    Effort: Overnight · Risk: None

    Disable XMP or EXPO and run MemTest86 for at least four passes. If errors appear, test modules individually in the same slot. If the modules are clean at stock but fail with the profile enabled, the profile is the problem rather than the memory.

  4. Remove third-party security and encryption software

    Effort: 30 minutes · Risk: Low

    Anti-virus file-system filters and third-party disk encryption sit directly in the I/O path this bugcheck depends on. Uninstall with the vendor's removal tool, not just the standard uninstaller, and run on Windows Defender for a few days.

  5. Verify system files

    Effort: 30 minutes · Risk: None

    Run in order:

    1. sfc /scannow
    2. DISM /Online /Cleanup-Image /RestoreHealth
    3. sfc /scannow again

  6. Clean-install the display driver

    Effort: 20 minutes · Risk: Low

    A late step, but worth doing if everything else is clean and the crashes cluster around graphics activity. Use DDU from Safe Mode, then install the vendor's current package.

When it is the hardware, not Windows

This bugcheck leans hardware more than most. These make it near-certain:

If the drive is the cause, act sooner rather than later. Unlike a bad memory module - which crashes the machine but does not usually destroy data - a failing drive takes your files with it. Copy anything irreplaceable off before you spend a week on driver troubleshooting, because the diagnostic work is not urgent and the backup is.

Frequently asked

Should I just leave memory compression disabled?

Not as a solution. If disabling it stops the crashes, you have learned where the fault surfaces, not what causes it. The underlying problem - a failing drive, bad memory, a filter driver - is still there and will reappear in another form. Compression also genuinely helps performance on machines with limited RAM, so turning it off permanently costs you something real. Use it as a test, then re-enable it and keep looking.

The name says 'store'. Is that the Microsoft Store?

No, and the collision is unfortunate. 'Store' here means the compressed memory store managed by the store manager, which has nothing to do with the app store. Reinstalling or resetting the Microsoft Store will not affect this bugcheck at all - advice suggesting otherwise has confused the two.

Why check the drive first when the error is about memory?

Because the store manager sits at the boundary between the two. It handles compressed pages in RAM but also writes them out and interacts with the page file, so a disk that returns errors or stalls generates exceptions inside a memory component. Checking SMART data takes twenty minutes and rules out the most likely cause before you spend an evening testing RAM.

Can this be caused by a full disk?

Indirectly, yes. A system volume with very little free space constrains the page file and leaves the store manager with nowhere to work. It is not the usual cause, but if the drive is nearly full, freeing several gigabytes is a sensible thing to do early - it is quick and it removes a variable.