WindowsAdvanced

How to Fix MSRPC_STATE_VIOLATION Blue Screen Error (0x00000112) in Windows

Quick Answer MSRPC_STATE_VIOLATION (0x00000112) is a Windows Blue Screen of Death (BSOD) error indicating that the Microsoft Remote Procedure Call (MSRPC) dr...

Bison Technical Team Enterprise IT specialists

Updated 10 Nov 2026 17 min read 0 total views

Structured technical guidanceSafety notes included where requiredSources listed below

Quick Answer

MSRPC_STATE_VIOLATION (0x00000112) is a Windows Blue Screen of Death (BSOD) error indicating that the Microsoft Remote Procedure Call (MSRPC) driver, identified as Msrpc.sys, detected an invalid internal state and initiated a system bug check.

According to Microsoft, the most common documented cause is that a component calling the MSRPC driver violated the expected state rules for an operation. This can involve invalid RPC binding handles, asynchronous RPC operations, or incorrect handling of RPC sessions and communication objects.

This is primarily a kernel-mode programming and driver-related error. It does not automatically indicate that the RPC service is disabled, that Windows has a network connectivity problem, or that the Msrpc.sys file itself is damaged.

For affected users, the recommended approach is to identify the component or driver associated with the crash, examine the Windows crash dump, undo recent driver or software changes where appropriate, and apply verified updates. Reinstalling Windows or replacing system files should not be the first response.

What Is MSRPC_STATE_VIOLATION (0x00000112)?

MSRPC_STATE_VIOLATION is a Windows stop error, also known as a bug check, with the hexadecimal value 0x00000112.

MSRPC stands for Microsoft Remote Procedure Call. Remote Procedure Call (RPC) is a communication mechanism that allows one software component to request an operation from another component, even when the components operate in different processes or on different systems.

Windows uses RPC extensively for communication between operating system components, services, applications and network-related functionality.

The Windows MSRPC driver manages important aspects of this communication. It expects RPC operations to follow specific rules governing object states, handles, calls, sessions and asynchronous operations.

When an operation violates these expected rules, the driver can detect the invalid state and initiate the MSRPC_STATE_VIOLATION bug check.

Microsoft documents this stop code in its Windows driver debugging reference:

Microsoft Learn: Bug Check 0x112 – MSRPC_STATE_VIOLATION

What Does the MSRPC_STATE_VIOLATION Blue Screen Look Like?

When Windows encounters this bug check, the computer displays a blue screen and stops normal operation.

The screen may display a message similar to:

Your PC ran into a problem and needs to restart.
We'll restart for you.

Stop code: MSRPC_STATE_VIOLATION

The exact appearance and additional information depend on the Windows version and system configuration.

Windows may automatically restart after collecting diagnostic information. If configured, it can also create a memory dump containing information about the system state at the time of the crash.

Understanding the 0x00000112 Bug Check Parameters

The MSRPC_STATE_VIOLATION bug check includes parameters that help identify the type of invalid operation detected by the MSRPC driver.

Microsoft identifies Parameters 1 and 2 as the primary parameters of interest. Parameter 1 identifies the state violation type, while the meaning of Parameter 2 depends on the first parameter.

Bug Check Parameter Reference

Parameter 1	Parameter 2	Documented Meaning
`0x01`	Exception code	A non-continuable exception was continued by the caller.
`0x02`	Error	The Advanced Local Procedure Call (ALPC) returned an invalid error.
`0x03`	Session to the server	The caller unloaded the MSRPC driver while it was still in use. Open binding handles may remain.
`0x04` and `0x05`	Session to the server	An invalid close command was received from ALPC.
`0x06`	Binding handle	An attempt was made to bind an RPC handle a second time.
`0x07`	Binding handle	An operation was attempted on a binding handle that had not been bound.
`0x08`	Binding handle	An attempt was made to set security information on a binding handle that was already bound.
`0x09`	Binding handle	An attempt was made to set an option on a binding handle that was already bound.
`0x0A`	Call object	An attempt was made to cancel an invalid asynchronous RPC.
`0x0B`	Call object	An attempt was made to push on an asynchronous pipe call when it was not expected.
`0x0C` and `0x0E`	Pipe object	An attempt was made to push on an asynchronous pipe without waiting for notification.
`0x0F`	Pipe object	An attempt was made to synchronously terminate a pipe a second time.
`0x15`	Object closest to the error	An internal RPC error occurred.
`0x16`	Reserved	Two causally ordered calls were issued in an order that cannot be enforced by RPC.
`0x17`	Call object	A server manager routine did not unsubscribe from notifications before completing the call.
`0x18`	Asynchronous handle	An invalid operation was performed on an asynchronous handle.

Important: These parameters describe internal RPC state violations. They are particularly useful when analyzing kernel crash dumps and debugging software that uses RPC. They are not ordinary Windows settings or error messages that users can directly correct.

The complete parameter reference is available in Microsoft's official MSRPC_STATE_VIOLATION documentation.

```html

Possible Causes of MSRPC_STATE_VIOLATION

Microsoft identifies violations of the expected MSRPC operation states as the most common cause of this bug check. The actual component responsible must be identified through debugging evidence.

The following are areas worth investigating when this error occurs:

1. Incorrect RPC Operations in a Driver

A kernel-mode driver or software component that uses RPC functionality may perform an operation in an invalid sequence. Examples include attempting to reuse an already-bound handle, performing an operation on an unbound handle, or incorrectly managing an asynchronous RPC call.

This is particularly relevant when a system crash occurs after installing or updating software that includes kernel-mode drivers or system-level components.

2. Driver Compatibility or Software Conflicts

An incompatible, defective or incorrectly implemented driver may interact with Windows components in an unexpected way.

Recently installed or updated drivers, endpoint security products, virtualization software and other low-level system utilities are reasonable candidates for investigation. However, their involvement must be established from crash analysis rather than assumed from the stop code alone.

3. Incorrect Handling of RPC Sessions and Handles

RPC communication relies on correctly managed sessions, binding handles and communication objects.

If a software component closes a session prematurely, unloads a driver while it remains in use, or performs an invalid operation on a communication object, the MSRPC driver may detect a state violation.

4. Windows Component or Driver Corruption

Damaged Windows components or driver files may contribute to system instability. Although this is a possible area to investigate, Microsoft does not identify corrupted Windows files as the primary documented explanation for this particular bug check.

5. Other System Instability

Unexpected system behavior can sometimes involve memory corruption or hardware instability. These should be investigated when additional diagnostic evidence supports them.

The MSRPC_STATE_VIOLATION stop code alone does not establish that RAM, the motherboard or another hardware component is defective.

How to Troubleshoot MSRPC_STATE_VIOLATION (0x00000112)

Follow the troubleshooting procedures below in order. Start with basic recovery and recent software changes before moving to advanced debugging.

Step 1: Restart Windows and Check Whether the Error Repeats

A single blue screen does not necessarily indicate a persistent problem. Windows may restart successfully after encountering a temporary system failure.

Allow Windows to complete the automatic restart.
Sign in normally.
Check whether the computer operates without further crashes.
Observe whether the error returns during a particular activity, application launch or system operation.
Record the stop code and any additional information displayed on the blue screen.

If the error occurs repeatedly, continue with the following steps.

Step 2: Disconnect Recently Added Hardware

New hardware can introduce incompatible drivers or unexpected interactions with existing system components.

Shut down the computer.
Disconnect recently added external devices such as USB peripherals, docking stations and expansion devices.
If an internal hardware component was recently installed, have it checked or temporarily removed by a qualified technician where appropriate.
Start Windows and check whether the problem persists.

Do not disconnect essential storage devices or internal components while the computer is operating.

If the error disappears after removing a particular device, investigate its driver, firmware and compatibility before reconnecting it.

Step 3: Start Windows in Safe Mode

Safe Mode starts Windows with a limited set of drivers and services. It can help determine whether the problem is associated with a third-party driver or startup component.

If Windows cannot start normally, use the Windows Recovery Environment (WinRE).

Enter Windows Recovery Environment. If Windows cannot boot, repeated interrupted startup attempts may cause Windows to enter automatic recovery.
Select Troubleshoot.
Select Advanced options.
Select Startup Settings.
Select Restart.
After restarting, press 4 or F4 to enable Safe Mode.
Observe whether Windows operates normally in Safe Mode.

If the error does not occur in Safe Mode, investigate third-party drivers, services and startup applications. This result narrows the investigation but does not conclusively identify the responsible component.

For additional instructions, refer to Microsoft Support: Windows Startup Settings.

Step 4: Roll Back or Update Recently Changed Drivers

If the blue screen started after installing or updating a driver, investigate that driver first.

Start Windows normally or in Safe Mode.
Right-click the Start button.
Select Device Manager.
Expand the relevant hardware category.
Locate the device whose driver was recently changed.
Right-click the device and select Properties.
Open the Driver tab.
If available, select Roll Back Driver.
Follow the instructions and restart the computer.

If rolling back is unavailable or the existing driver is known to be defective, obtain a compatible replacement from the computer manufacturer or hardware manufacturer's official support website.

Prioritize drivers that were recently installed or that appear in the crash investigation. Avoid updating every driver indiscriminately.

Step 5: Uninstall Recently Installed Software

Some applications install system-level drivers or services that operate with Windows kernel components.

If the problem began immediately after installing a particular application, temporarily uninstalling it can help identify a software conflict.

Open Windows Settings.
Select Apps.
Open Installed apps or Apps & features, depending on the Windows version.
Identify recently installed software.
Uninstall the suspected application using its normal uninstall procedure.
Restart Windows.
Monitor the computer for recurring blue screen errors.

Pay particular attention to recently installed system utilities, security software, virtualization tools and applications that install kernel-mode drivers.

Do not disable security protection permanently. If an endpoint security product is suspected, use the vendor's supported troubleshooting or temporary removal procedure, particularly on business-managed computers.

Step 6: Install Available Windows Updates

Windows updates can include operating system fixes, driver compatibility improvements and security updates.

Open Settings.
Select Windows Update.
Select Check for updates.
Review available updates.
Install appropriate updates.
Restart the computer if required.

For business-critical computers, test updates according to the organization's change-management procedures before deploying them widely.

Windows version consideration: Windows 10 reached the end of standard support on October 14, 2025. Devices running Windows 10 should follow Microsoft's applicable support and Extended Security Updates arrangements, where eligible. Windows 11 users should install supported updates for their particular release.

Official reference: Microsoft Support: Troubleshooting Windows Unexpected Restarts and Stop Code Errors.

Step 7: Repair Windows System Files

If Windows system corruption is suspected, use the built-in Deployment Image Servicing and Management (DISM) and System File Checker (SFC) utilities.

These tools check and repair Windows component-store and protected system-file problems. They are general Windows integrity checks, not specific fixes for every MSRPC_STATE_VIOLATION crash.

Procedure:

Right-click the Start button.
Select Terminal (Admin) or Command Prompt (Admin).
Approve the User Account Control prompt.
Run the following command:

DISM /Online /Cleanup-Image /RestoreHealth

Wait for the operation to complete. DISM may use Windows Update as a repair source, so an internet connection may be required.

Next, execute:

sfc /scannow

Allow System File Checker to complete its verification and repair process.

Restart Windows after both operations have finished.

Important: If DISM reports that it cannot find source files, a compatible Windows repair source may be required. Do not use an arbitrary Windows image or files from another incompatible Windows installation.

Official reference: Microsoft Learn: Repair a Windows Image.

Step 8: Check the System for Memory Problems

Although memory failure is not the primary documented cause of MSRPC_STATE_VIOLATION, memory instability can cause unpredictable system behavior and should be investigated if other evidence suggests it.

Windows includes a built-in diagnostic utility called Windows Memory Diagnostic.

Press Windows + R.
Type mdsched.exe.
Press Enter.
Select Restart now and check for problems after saving your work.
Allow the diagnostic test to complete.
After Windows restarts, review the diagnostic result.

If memory errors are reported, further testing may be required to identify a defective memory module, unstable memory configuration or another hardware issue.

For business-critical systems, arrange appropriate maintenance before removing or replacing memory modules.

Step 9: Perform a Clean Boot

A clean boot starts Windows with a minimal set of startup programs and non-Microsoft services. It can help isolate software conflicts.

Press Windows + R.
Type msconfig and press Enter.
Open the Services tab.
Select Hide all Microsoft services.
Select Disable all for the remaining services.
Open the Startup tab.
Select Open Task Manager.
Disable non-essential startup applications.
Restart the computer.

Check whether the blue screen continues to occur.

If the problem disappears, re-enable services and startup applications in controlled groups to identify the conflicting component.

Warning: Do not disable Microsoft services indiscriminately. Also, do not leave essential security, backup or business services disabled after testing.

Advanced Troubleshooting: Analyze the Windows Crash Dump

If MSRPC_STATE_VIOLATION continues to occur, analyzing the Windows memory dump is one of the most useful ways to investigate the underlying cause.

A crash dump records diagnostic information about the system when the bug check occurs. It can help identify the failing operation, involved modules, driver activity and the context in which the crash happened.

1. Locate the Crash Dump File

Windows may create a small memory dump or a larger kernel or automatic memory dump, depending on the configured system failure settings.

Common dump file locations include:

Dump Type	Default Location
Small memory dump	`C:\Windows\Minidump\`
Kernel memory dump	`C:\Windows\MEMORY.DMP`
Automatic memory dump	`C:\Windows\MEMORY.DMP`

Open File Explorer and check whether these locations contain dump files.

If no dump file exists, check the Startup and Recovery configuration and ensure that the system has the necessary paging-file and disk-space configuration.

2. Enable Automatic Memory Dump Collection

If Windows is not currently generating useful crash dumps, configure its startup and recovery settings.

Open Windows Search.
Search for Advanced system settings.
Open the corresponding Control Panel setting.
Select the Advanced tab.
Under Startup and Recovery, select Settings.
Locate Write debugging information.
Select Automatic memory dump, where available.
Confirm the settings.
Restart Windows.

Administrator permissions may be required. Make sure adequate disk space and appropriate paging-file settings are available.

Official reference: Microsoft Learn: Configure System Failure and Recovery Options.

3. Analyze the Dump Using WinDbg

WinDbg is Microsoft's debugging tool for investigating application and Windows kernel crashes. It can analyze memory dump files and provide information about the bug check and the modules involved.

This procedure is intended for IT professionals and advanced users.

Obtain WinDbg from Microsoft's official distribution channel.
Install and open WinDbg.
Select File > Open dump file, or press Ctrl + D.
Browse to the relevant .dmp file.
Open the dump file and allow symbols to load.
Enter the following command in the debugger command window:

!analyze -v

This command performs a detailed automatic analysis of the crash dump.

To display the bug check code and its parameters, execute:

.bugcheck

To inspect loaded modules, execute:

lm

Review the output for:

The bug check code and its four parameters.
The reported failure context.
The stack trace.
Modules and drivers involved in the execution path.
Any third-party drivers appearing in the relevant stack.
Repeated patterns across multiple crash dumps.

Important: A module appearing in a crash stack does not automatically mean that it is defective. Likewise, a report identifying Msrpc.sys as the bug-checking module does not prove that the Microsoft driver itself is the original source of the problem.

The responsible component may be another driver or software component that made an invalid RPC call.

Official references:

4. Compare Multiple Crash Dumps

If the computer has experienced several MSRPC_STATE_VIOLATION crashes, compare their dump files rather than relying on a single crash report.

Look for recurring patterns such as:

The same third-party driver appearing in multiple stack traces.
The same parameter 1 value across crashes.
Repeated failures involving a particular RPC operation.
A consistent relationship with a particular application or system activity.
Crashes beginning after a specific driver or software update.

Repeated evidence can help narrow down the responsible component.

What Should You Avoid When Fixing This Error?

Several commonly suggested troubleshooting methods may be ineffective or unnecessarily risky when applied without identifying the actual cause.

Do not replace Msrpc.sys with a downloaded copy: Obtain Windows system files through supported Windows servicing and repair mechanisms.
Do not download random DLL or SYS files: Files from unofficial websites may be incompatible or malicious.
Do not disable RPC services: Windows depends on RPC functionality for many essential operations.
Do not edit RPC-related registry entries without evidence: Incorrect changes can affect Windows services and system functionality.
Do not disable driver signature enforcement as a permanent workaround: This weakens an important Windows security protection.
Do not reinstall Windows immediately: A reinstall may not resolve a defect in third-party software or a faulty driver.
Do not assume that hardware is defective: The bug check specifically identifies an MSRPC state violation, not a confirmed hardware failure.

When Should You Contact Technical Support?

Contact Microsoft Support, the computer manufacturer or the relevant software vendor if:

The blue screen continues after basic troubleshooting.
Windows repeatedly crashes during normal operation.
The system cannot start normally or in Safe Mode.
Crash dumps consistently identify a particular third-party driver or software component.
The issue affects a business-critical server or workstation.
The error began after a major operating system, driver or firmware change.
Advanced debugging is required to identify an RPC programming defect.

When requesting support, provide the following information where available:

Windows edition, version and build number.
Computer manufacturer and model.
Recent driver, software and hardware changes.
The exact stop code and bug check parameters.
Relevant crash dump files.
WinDbg analysis output.
Steps that consistently reproduce the crash.

Crash dump files can contain sensitive information from system memory. Review organizational privacy and security requirements before sharing them with third parties.

How to Prevent MSRPC_STATE_VIOLATION Errors

Although this error cannot always be prevented through normal user maintenance, the following practices can reduce the likelihood of driver and software compatibility problems.

Install Windows updates applicable to the installed Windows version.
Use drivers supplied by the hardware manufacturer or computer manufacturer.
Verify driver compatibility before deploying new hardware.
Keep security software and system-level applications updated.
Remove obsolete drivers and applications using supported uninstall procedures.
Test major driver and software changes before deploying them across business systems.
Maintain regular backups of important files and business data.
Monitor recurring system crashes and retain relevant diagnostic information.
Use crash dump analysis to identify recurring driver or software failures.
Ensure that kernel-mode drivers and RPC-using software are properly developed and tested.

Frequently Asked Questions (FAQs)

1. What does MSRPC_STATE_VIOLATION mean?

MSRPC_STATE_VIOLATION means that the Windows MSRPC driver detected an invalid state during an RPC-related operation and initiated a system bug check. The associated stop code is 0x00000112.

2. What is the main cause of error 0x00000112?

According to Microsoft, the most common cause is that a caller of the Msrpc.sys driver violated the expected state semantics of an RPC operation. The specific component responsible must be identified through debugging and system evidence.

3. Is Msrpc.sys responsible for the blue screen?

Msrpc.sys initiates the bug check when it detects an invalid RPC state. However, this does not necessarily mean that Msrpc.sys is defective. The component making the invalid RPC call may be responsible.

4. Can a third-party driver cause MSRPC_STATE_VIOLATION?

A driver or software component that uses RPC incorrectly can potentially trigger this bug check. Crash dump analysis is required to establish whether a particular third-party driver is involved.

5. Is MSRPC_STATE_VIOLATION related to the Remote Procedure Call service?

The error is related to the Microsoft Remote Procedure Call subsystem, but it specifically describes an internal state violation detected by the MSRPC driver. It does not automatically mean that the Windows Remote Procedure Call service is stopped or disabled.

6. Can SFC and DISM fix MSRPC_STATE_VIOLATION?

SFC and DISM can repair certain Windows component and system-file integrity problems. They may help if Windows corruption contributes to the issue, but they cannot correct an underlying programming defect in a third-party driver.

7. Does this error indicate faulty RAM?

No. The stop code does not directly indicate a memory hardware failure. Memory diagnostics may be useful if other symptoms or crash analysis suggest memory instability.

8. Where can I find MSRPC_STATE_VIOLATION crash dump files?

Small memory dumps are generally stored in C:\Windows\Minidump\. Kernel and automatic memory dumps are generally stored as C:\Windows\MEMORY.DMP, depending on the system configuration.

9. Can I fix this error by reinstalling Windows?

Reinstalling Windows may help if the underlying problem is related to Windows installation corruption. However, it may not resolve an incompatible third-party driver or software defect. Diagnose the crash before considering a reinstall.

10. Is MSRPC_STATE_VIOLATION a network error?

Not necessarily. RPC can be used for communication between local processes as well as across systems. This bug check identifies an invalid RPC state, not simply a network connectivity failure.

Conclusion

MSRPC_STATE_VIOLATION (0x00000112) is a Windows kernel bug check associated with invalid state handling in the Microsoft Remote Procedure Call subsystem.

Microsoft identifies incorrect use of the MSRPC driver as its most common documented cause. Therefore, the most effective troubleshooting approach is to identify the component performing the invalid operation rather than immediately replacing Windows system files or changing unrelated services.

For ordinary users, checking recent software and driver changes, testing Safe Mode and installing appropriate updates are reasonable starting points. For recurring crashes, memory dump analysis with WinDbg provides a more reliable way to investigate the failure and identify potentially responsible components.

Official References

YOUR FEEDBACK

Was this guide useful?

Your answer helps us keep BISONKB accurate and practical.