Fix 0x00000049 PAGE_FAULT_WITH_INTERRUPTS_OFF in Windows
Quick Answer PAGE_FAULT_WITH_INTERRUPTS_OFF is Windows bug check 0x00000049. Microsoft describes it as very infrequent and recommends using the !analyze debu...
Quick Answer
PAGE_FAULT_WITH_INTERRUPTS_OFF is Windows bug check 0x00000049. Microsoft describes it as very infrequent and recommends using the !analyze debugger extension to investigate. Its reference page does not publish a parameter table, detailed cause, or specific repair procedure. Microsoft Learn
The practical approach is to preserve the crash dump, review recent system changes, and investigate drivers identified by the evidence. If normal startup is unstable, use Safe Mode to perform a targeted rollback.
What Does This Error Mean?
The symbolic name describes a page fault occurring with interrupts disabled. However, the name alone does not identify the responsible driver, memory address, or underlying defect.
| Item | Documented information |
|---|---|
| Stop code | 0x00000049 |
| Symbolic name | PAGE_FAULT_WITH_INTERRUPTS_OFF |
| Frequency | Very infrequent |
| Bug-check parameter definitions | Not provided on Microsoft’s reference page |
| Recommended diagnostic tool | !analyze debugger extension |
Avoid applying parameter definitions from a different page-fault stop code to this error. Microsoft Learn
Technical background
Windows places restrictions on memory access at elevated interrupt request levels, or IRQLs. Microsoft documents that driver routines above APC_LEVEL cannot safely access paged-pool memory and that a page fault at those levels is fatal. This is relevant background, not a documented explanation of every 0x49 crash. Microsoft Learn
Before You Begin
- Back up important files while Windows remains accessible.
- Record the exact stop code and crash time.
- Note recent driver, application, hardware, or firmware changes.
- Record what the computer was doing immediately before the failure.
- Preserve existing crash dumps before making changes.
Have administrator access available for driver maintenance. If you need recovery options on an encrypted computer, have the BitLocker recovery key ready. support.microsoft.com
How to Troubleshoot 0x00000049
1. Establish a timeline
Determine whether the first crash followed an identifiable change. Record:
- The component installed or updated.
- Its previous and current version, if known.
- Whether the same activity triggers subsequent crashes.
- Whether all crashes show the same stop code.
Microsoft’s general stop-error guidance recommends reviewing recent changes and investigating components identified by crash evidence. A recent installation is a useful lead, but timing alone does not prove responsibility. learn.microsoft.com
2. Roll back a relevant driver update
If failures began immediately after a particular device driver update:
- Open Device Manager.
- Locate the device and open Properties.
- Select the Driver tab.
- Choose Roll Back Driver, if available.
- Follow the prompts and restart Windows.
Driver rollback requires administrator privileges. The option may be unavailable if Windows has no previous driver to restore. support.microsoft.com
Make one targeted change at a time and record its result.
3. Install a compatible driver when appropriate
If a driver is implicated and rollback is unsuitable, check Windows Update or the manufacturer’s official support site for a compatible package. Match the package to the device model and Windows version. Microsoft advises avoiding unofficial driver download sites. support.microsoft.com
For drivers bundled with an application, use the application vendor’s supported maintenance process. Keep the previous installer or recovery instructions available in case the replacement introduces another problem.
4. Use Safe Mode if Windows cannot remain stable
From Windows Recovery Environment:
- Select Troubleshoot → Advanced options → Startup Settings → Restart.
- Press 4 or F4 for Safe Mode.
- Attempt the relevant driver rollback.
Safe Mode starts Windows with a limited set of drivers and services. If the problem disappears there, that helps narrow the investigation but does not identify a particular driver. Restart normally after maintenance. support.microsoft.com
Analyze the Crash Dump
1. Locate the dump
Check these default locations:
| Dump type | Default location |
|---|---|
| Small memory dump | %SystemRoot%\Minidump |
| Kernel or automatic memory dump | %SystemRoot%\MEMORY.DMP |
Files are present only if Windows was configured and able to save them. Copy the relevant dump before further troubleshooting. learn.microsoft.com
2. Configure collection if necessary
If crashes recur without a useful dump:
- Search Windows for Advanced system settings.
- Open Advanced → Startup and Recovery → Settings.
- Under Write debugging information, select Automatic memory dump.
- Save the setting and restart.
This prepares collection for a future failure; it cannot recover a previous crash’s missing data. learn.microsoft.com
3. Run WinDbg analysis
Open the dump in WinDbg with appropriate symbols configured, then run:
!analyze -v
Review the reported bug check, stack, and module information. Microsoft recommends this analysis approach for investigating stop errors. learn.microsoft.com
Treat an identified module as an investigative lead. Check whether its role is consistent with the stack, recent changes, and other dumps before deciding to replace or remove it.
4. Recognize dump limitations
A small memory dump contains limited crash context. Microsoft notes that it may not reveal errors whose underlying cause occurred outside the thread executing when the system stopped. If analysis is inconclusive, a support engineer may need a kernel or automatic dump from another occurrence. Microsoft Learn
Verify the Result
After applying a targeted change:
- Restart Windows normally.
- Confirm the expected driver or software version is installed.
- Repeat the affected workflow using noncritical data.
- Observe several sessions if the failure was intermittent.
- Preserve any new dump and compare it with the earlier crash.
A successful restart alone does not establish that the fault is resolved.
Frequently Asked Questions
Does this error prove the RAM is faulty?
No. The stop-code name alone is insufficient evidence for replacing RAM. Use crash analysis and any independent hardware-test results to guide that decision.
Will increasing the page file fix it?
Microsoft’s 0x49 reference does not document page-file enlargement as a remedy. Page-file configuration can matter for dump collection, which is a separate diagnostic concern.
Should I change interrupt settings in the BIOS?
The symbolic name does not identify a BIOS setting to change. Follow hardware-vendor guidance only when the investigation supports a specific firmware or configuration issue.
What if Safe Mode works correctly?
Use that opportunity to preserve dumps and reverse a relevant recent change. Safe Mode stability narrows the investigation without proving which component is responsible.
What should I send to technical support?
Provide the dump, Windows version, hardware model, recent change history, driver versions, reproduction steps, and !analyze -v output.
Conclusion
Investigate 0x00000049 through crash evidence and targeted changes. Preserve the dump, review the system’s recent history, and verify any driver correction against the workflow that previously failed.
Sources
- Microsoft Learn — Bug Check 0x49: PAGE_FAULT_WITH_INTERRUPTS_OFF
- Microsoft Learn — Managing hardware priorities
- Microsoft Learn — Advanced troubleshooting for stop code errors
- Microsoft Support — Update drivers through Device Manager in Windows
- Microsoft Support — Windows startup settings
- Microsoft Learn — Small Memory Dump
Was this guide useful?
Your answer helps us keep BISONKB accurate and practical.