Get-WindowsUpdateLog triggers Microsoft Attack Surface Reduction (ASR) Rules

We were trying to diagnose a problem with Windows Updates today using Get-WindowsUpdateLog on Windows Server 2019. We kept getting blocked by ASR rule C0033C00-D16D-4114-A5A0-DC9B3A7D2CEB (Block use of copied or impersonated system tools) which kept tripping on the script’s use of tracerpt.exe which is supposed to be located in C:\Windows\System32.

We kept getting this:

### PowerShell 5
PS C:\> Get-WindowsUpdateLog
Converting C:\Windows\logs\WindowsUpdate into C:\Users\me\Desktop\WindowsUpdate.log ...
Program 'tracerpt.exe' failed to run: Access is deniedAt C:\Windows\system32\WindowsPowerShell\v1.0\Modules\WindowsUpdate\WindowsUpdateLog.psm1:193 char:5
+     & "$WORKDIR\tracerpt.exe" $args | Out-Default
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~.
At C:\Windows\system32\WindowsPowerShell\v1.0\Modules\WindowsUpdate\WindowsUpdateLog.psm1:193 char:5
+     & "$WORKDIR\tracerpt.exe" $args | Out-Default
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
    + FullyQualifiedErrorId : NativeCommandFailed
Failed to decode ETLs. TraceRpt.exe returned error=
At C:\Windows\system32\WindowsPowerShell\v1.0\Modules\WindowsUpdate\WindowsUpdateLog.psm1:201 char:9
+         throw "Failed to decode ETLs. TraceRpt.exe returned error= $L ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Failed to decod...eturned error= :String) [], RuntimeException
    + FullyQualifiedErrorId : Failed to decode ETLs. TraceRpt.exe returned error=


### PowerShell 7.x
PS C:\> Get-WindowsUpdateLog
Converting C:\Windows\logs\WindowsUpdate into C:\Users\me\Desktop\WindowsUpdate.log ...
ResourceUnavailable: Program 'tracerpt.exe' failed to run: An error occurred trying to start process 'C:\Users\me\AppData\Local\Temp\2\WindowsUpdateLog\tracerpt.exe' with working directory
'C:\Users\me\AppData\Local\Temp\2\WindowsUpdateLog\SymCache'. Access is denied.At
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\WindowsUpdate\WindowsUpdateLog.psm1:193 char:5 +     & "$WORKDIR\tracerpt.exe" $args | Out-Default +
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~.
Exception: Failed to decode ETLs. TraceRpt.exe returned error=

Looking in the Windows Event Viewer we’d see:

Log Name:      Microsoft-Windows-Windows Defender/Operational
Source:        Microsoft-Windows-Windows Defender
Date:          2026-06-09 14:24:55
Event ID:      1121
Task Category: None
Level:         Warning
Keywords:      
User:          SYSTEM
Computer:      myserver.local
Description:
Microsoft Defender Exploit Guard has blocked an operation that is not allowed by your IT administrator.
 For more information please contact your IT administrator.
    ID: C0033C00-D16D-4114-A5A0-DC9B3A7D2CEB
    Detection time: 2026-06-09T21:24:55.545Z
    User: mydomain\me
    Path: C:\Users\me\AppData\Local\Temp\2\WINDOW~1\tracerpt.exe
    Process Name: C:\Program Files\PowerShell\7\pwsh.exe
    Target Commandline: 
    Parent Commandline: "C:\Program Files\PowerShell\7\pwsh.exe" -WorkingDirectory ~
    Involved File: 
    Inheritance Flags: 0x00000000
    Security intelligence Version: 1.453.12.0
    Engine Version: 1.1.26050.11
    Product Version: 4.18.26050.15

Testing on a Windows Server 2025 machine, everything worked fine in both PowerShell 5.x and 7.x.

I then did a comparison of C:\Windows\system32\WindowsPowerShell\v1.0\Modules\WindowsUpdate\WindowsUpdateLog.psm1 on Server 2019 vs Server 2025 and found the problem.

It looks like Get-WindowsUpdateLog on Windows Server 2019 has a function called CopyDependencies and on Server 2025 it does not:

# Snippet from C:\Windows\system32\WindowsPowerShell\v1.0\Modules\WindowsUpdate\WindowsUpdateLog.psm1 on Windows Server 2019
function CopyDependencies
{
    Write-Verbose "Initializing ..."
    New-Item -Path $WORKDIR -ItemType Directory -ErrorAction SilentlyContinue | Out-Null
    Copy-Item -Path $TRACERPT_EXE_PATH -Destination $WORKDIR -Force -ErrorAction Stop
    Copy-Item -Path $DBGHELP_DLL_PATH -Destination $WORKDIR -Force -ErrorAction Stop
    #
    # Find TraceRpt.exe's MUI files which could be in many different folders like en-US, zh-CN, etc. Look for all of them and copy to our work dir.
    #
    $test = Get-ChildItem -Directory "$env:SystemRoot\System32"
    Get-ChildItem -Directory "$env:SystemRoot\System32" | ForEach-Object {
        $sourceMUI = "$($_.FullName)\tracerpt.exe.mui"
        if (Test-Path $sourceMUI)
        {
            $destFolder = "$WORKDIR\$($_.Name)"
            $destMUI = "$destFolder\tracerpt.exe.mui"
            New-Item -Path $destFolder -ItemType Directory -ErrorAction SilentlyContinue | Out-Null
            Copy-Item -Path $sourceMUI -Destination $destMUI -Force -ErrorAction Stop
        }
    }
    Write-Verbose "Done."
}

The problem is the the Copy-Item calls that duplicate tracerpt.exe and dbghelp.dll into $WORKDIR“. Per the description of the ASR rule being triggered we can see why it doesn’t like this:

This ASR rule blocks the propagation and use of executable files identified as copies (duplicates or imposters) of Windows system tools. Some malicious programs might try to copy or impersonate Windows system tools to avoid detection or gain privileges. Allowing such executable files can lead to potential attacks.

Creating an exception for C:\Windows\System32\tracerpt.exe did not help because the ASR rule was being triggered off the copy, not the source.

Seems Microsoft knew this was going to be a problem and fixed it in Server 2025 (and probably 2022 but I don’t have one to test on) but not Server 2016 or 2019. Neither 2016 nor 2019 are EOL so I don’t know why Microsoft didn’t backport this fix. Then again, it’s Microsoft.

We got around the problem by copying C:\Windows\system32\WindowsPowerShell\v1.0\Modules\WindowsUpdate\WindowsUpdateLog.psm1 from a Server 2025 machine to C:\Temp\ and then running the following PowerShell:

PS C:\> cd temp
PS C:\Temp> Import-Module .\WindowsUpdateLog.psm1
PS C:\Temp> Get-WindowsUpdateLog

If you don’t have a Server 2022 or 2025 machine lying around, I think you can just pilfer the same script from Windows 11. I did a quick check and the Windows 11 version does not try to copy tracerpt.exe like Server 2016/2019 does. I only checked Windows 11 25H2.

This workaround avoids breaking anything in Server 2019 and is temporary. The native Get-WindowsUpdateLog is only replaced as long as your PowerShell terminal is open. If you close/re-open you’re back to the OS’ native version of that command.

Hopefully this saves someone else 2 hours of troubleshooting.