Event ID 3076 and 3077 — CodeIntegrity driver audit and enforcement

If you found these event IDs in Windows Event Viewer, a driver on your system has been flagged by Microsoft's Vulnerable Driver Blocklist — either in audit mode (3076) or enforcement mode (3077). This page explains what each event means, how to identify the affected driver from the event data, and what options are available.

Where to find these events

Open Event Viewer and navigate to:

Applications and Services Logs → Microsoft → Windows → CodeIntegrity → Operational

Right-click the log and choose Filter Current Log. Enter 3076 or 3077 in the Event ID field. You can filter for both at once by entering 3076,3077.

What each event ID means

Event 3076 — Audit (driver loaded, violation logged)

Windows loaded the driver but logged it as a policy violation. The device continues to function. This is the audit phase — the system is warning you before it starts blocking. The event message reads roughly: “Code Integrity determined that a process attempted to load [filename] that did not meet the signing level requirements. However, because of the Code Integrity policy, the image was allowed to load.”

If you are seeing 3076, you are in the warning window. The driver will be blocked after approximately 100 hours of active system uptime and 3 reboots (2 on Windows Server).

Event 3077 — Enforcement (driver blocked)

Windows blocked the driver from loading. The device will fail to initialize — Device Manager typically shows a yellow exclamation mark or error code 39/45. The event message reads roughly: “Code Integrity determined that a process attempted to load [filename] that did not meet the signing level requirements. The image load was blocked.”

If you are seeing 3077, the driver is actively blocked. Audit mode has already passed.

Reading the event to identify the driver

Click on a 3076 or 3077 event to expand it. In the Details tab (switch to XML view for the cleanest read), look for the File Name field — it contains the full Windows device-object path to the blocked driver, for example:

\Device\HarddiskVolume3\Windows\System32\drivers\example.sys

The last segment is the driver filename. Cross-reference it against the device in Device Manager or the application logs of the software that stopped working.

The event also includes a Policy GUID (under PolicyGuid in the XML). This identifies which code integrity policy triggered the block. For drivers blocked by the Vulnerable Driver Blocklist via KB5083769, the policy GUID will match Microsoft's driver block policy; consult Microsoft's recommended driver block rules to confirm.

The audit-to-enforcement transition

The Windows Driver Policy document describes the transition mechanic. After KB5083769 installs:

  1. The policy enters audit mode. Affected drivers still load. Event 3076 is logged on each load attempt.
  2. After approximately 100 hours of active system uptime and 3 reboots (2 on Windows Server), the policy transitions to enforcement mode automatically.
  3. From enforcement onward, the driver is blocked. Event 3077 is logged. The device or application that depends on the driver stops functioning.

For machines that received KB5083769 in April 2026, the transition has almost certainly already occurred. Systems seeing 3076 now likely received the update recently (e.g., through a delayed update cycle or a fresh Windows install).

If the blocked driver is a USB device driver

If the File Name in the event belongs to a USB peripheral — a lab instrument, measurement device, programmer, legacy dongle, or custom USB hardware — and the vendor is not actively maintaining the driver, the WinUSB-rebind path is a viable engineering remediation.

The approach replaces the vendor's kernel driver with Microsoft's in-box winusb.sys and a user-mode implementation of the device protocol. No kernel signing, no WDAC policy edits.

The decision tree checks the seven conditions that determine whether your specific device is a rebind candidate. It takes about two minutes and produces a clear verdict.

The pattern page explains the full technical approach — INF, user-mode protocol shim, and scheduled-task persistence.

If the blocked driver is not a USB device driver

The WinUSB-rebind pattern only applies to USB device drivers. If the blocked driver is:

  • A backup software driver (e.g., psmounterex.sys used by Macrium Reflect, Acronis, NinjaOne, UrBackup) — the fix comes from the vendor. Check the vendor's support site for an updated version with a re-signed driver.
  • A filesystem, storage, or network driver— these require vendor re-signing through Microsoft's Partner Center attestation, or a WDAC policy change processed through your Change Advisory Board.
  • A driver in a regulated or safety-critical environment— follow your organisation's change management process. The supported path is vendor re-signing, not a workaround toolkit.

Sources