JLR MONGOOSE Application Control policy has blocked

• Enter BIOS/UEFI → disable Secure Boot
• Open an elevated command prompt:

bcdedit /set testsigning on
bcdedit /set nointegritychecks on

• Reboot. You'll see a "Test Mode" watermark on the desktop, but dtmonpro.sys should load.

$DriverPath = "C:\Windows\System32\drivers\dtmonpro.sys"
New-CIPolicy -FilePath "C:\Policies\MongooseAllow.xml" -DriverFiles $DriverPath -Level Hash -UserPEs
ConvertFrom-CIPolicy "C:\Policies\MongooseAllow.xml" "C:\Policies\MongooseAllow.p7b"
Copy-Item "C:\Policies\MongooseAllow.p7b" "C:\Windows\System32\CodeIntegrity\CiPolicies\Active\"

Gemini said:

This is a known issue hitting more people after recent Windows 11 updates. Microsoft has tightened Kernel-Mode Code Signing (KMCS) enforcement — your Event Viewer confirms it: the system now demands Signing Level 4 (Microsoft/WHQL-signed) but dtmonpro.sys from Drew Technologies only validates at Level 1. Once Windows enforces this at the Code Integrity level, registry tweaks, Smart App Control, or Memory Integrity toggles won't help.

Here are your realistic options:

1. Disable Secure Boot + Enable Test Signing (quickest)

• Enter BIOS/UEFI → disable Secure Boot
• Open an elevated command prompt:

Code:

bcdedit /set testsigning on
bcdedit /set nointegritychecks on

• Reboot. You'll see a "Test Mode" watermark on the desktop, but dtmonpro.sys should load.

2. WDAC Hash Whitelist (keeps Secure Boot on)

You can whitelist the driver by its SHA256 hash (visible in your Event Viewer: 2B5F82EB66F99BF5E504CCD6768F5F77D47B620F1725D913C6CB03E96EE7B71A) using a custom Code Integrity supplemental policy:

Code:

$DriverPath = "C:\Windows\System32\drivers\dtmonpro.sys"
New-CIPolicy -FilePath "C:\Policies\MongooseAllow.xml" -DriverFiles $DriverPath -Level Hash -UserPEs
ConvertFrom-CIPolicy "C:\Policies\MongooseAllow.xml" "C:\Policies\MongooseAllow.p7b"
Copy-Item "C:\Policies\MongooseAllow.p7b" "C:\Windows\System32\CodeIntegrity\CiPolicies\Active\"

Reboot after deploying. More involved, but keeps your system security mostly intact.

3. Dedicated Windows 10 Installation (most reliable long-term)

Many people running JLR SDD/Pathfinder with Mongoose cables keep a separate Windows 10 LTSC partition or bootable SSD for diagnostics. Win10 LTSC 2021 doesn't enforce the Level 4 signing requirement and is the most hassle-free approach for workshop use.

4. Updated WHQL-signed driver (unlikely)

Drew Technologies was acquired by Opus IVS — they could theoretically release a properly WHQL-signed dtmonpro.sys, but given how long the Mongoose Pro JLR has been effectively EOL in their lineup, don't count on it.

Bottom line: Fastest fix is option 1. Cleanest fix while keeping security is option 2. Most reliable long-term is option 3.

If you try the WDAC policy route and run into trouble, post back with details.

Click to expand...

edd14 said:

Thank you this is great, i will try working on option 2.

In regards of whitelisting, do i need to w...

Click to expand...

Gemini said:

You don’t need to whitelist every SHA256 you see—only the specific hash(es) for the exact dtmonpro.sys instance Windows is blocking.

In Event Viewer, open the exact “Application Control policy has blocked…” event for dtmonpro.sys and take the File: path + the SHA256 listed in that same event. Whitelist that hash for that file/path.

If the event shows multiple SHA256 values, it’s usually because Windows is checking multiple components/instances (different copy/version/path of dtmonpro.sys, or multiple related driver objects). Only include the hashes that correspond to the blocked dtmonpro.sys shown in the File: line(s). Don’t add unrelated hashes from other events.

If you paste the full event text (especially the File: path and all SHA256 values shown in that same blocked event), I’ll tell you exactly which hashes to include.

Click to expand...

edd14 said:

- System







- Provider




Microsoft-Windows-CodeIntegrity




{4ee76bd8-3cf4-44a0-a0ac-3937...

Click to expand...

• SHA256: 2B5F82EB66F99BF5E504CCD6768F5F77D47B620F1725D913C6CB03E96EE7B71A
• SHA256 Flat: C3A5B6DBDA2EB38CF4AA46C2C1660148F4FF0B7F51D96E1BCFE6875E29C12B4A

Gemini said:

You only need to whitelist the SHA256 values that appear in that same blocked event for:

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

From your event, whitelist:

• SHA256: 2B5F82EB66F99BF5E504CCD6768F5F77D47B620F1725D913C6CB03E96EE7B71A
• SHA256 Flat: C3A5B6DBDA2EB38CF4AA46C2C1660148F4FF0B7F51D96E1BCFE6875E29C12B4A

Don’t whitelist any other SHA256s you might see from other events/copies—only those tied to this dtmonpro.sys block.

Click to expand...

edd14 said:

provide full steps. thanks

Click to expand...

• 1) Use only the SHA256s from that exact blocked event
  From your Microsoft-Windows-CodeIntegrity EventID 3077, the file/path is:
  
  Code:

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

  
  Whitelist these SHA256s (and do NOT use any other hashes from other events):
  • Code:

    2B5F82EB66F99BF5E504CCD6768F5F77D47B620F1725D913C6CB03E96EE7B71A

  • Code:

    C3A5B6DBDA2EB38CF4AA46C2C1660148F4FF0B7F51D96E1BCFE6875E29C12B4A

• 2) Confirm what policy type you’re editing
  Your event shows:
  
  Code:

  PolicyName: Microsoft Windows Cross Certificates for Code Integrity Exceptions Policy

  So you need a Code Integrity Exceptions–style whitelist/exception entry for the driver using the SHA256s above.
  
• 3) Add the exception entry (exact method depends on your tool/approach)
  Create an exception for the driver file using:
  • Target file: dtmonpro.sys (path shown in the event)
  • Hashing: SHA256
  • Hashes: add both SHA256 values from the event
• 4) Deploy / apply and reboot
  After updating the policy:
  • Apply the policy (according to the method you’re using)
  • Reboot (required in most cases for driver CI changes)
• 5) Verify
  Trigger Mongoose again and re-check:
  
  Code:

  Microsoft-Windows-CodeIntegrity / Operational

  You should no longer see the same block for dtmonpro.sys / EventID 3077.

edd14 said:

powershell

Click to expand...

• Windows version (10 or 11) and whether the policy is currently Audit or Enforce.
• The exact PolicyName from your EventID 3077 (full text), since it looks like “Microsoft Windows Cross Certificates for Code Integrity Exceptions Policy”.
• What you’re editing with PowerShell: do you already have an existing .cip</b> or .xml</b> policy file? If yes, paste its filename/path (where it’s stored).
  [*] Are you using Microsoft WDAC cmdlets (like ConvertFrom-CIPolicy / New-CIPolicy etc.), or a specific script/tool you downloaded?