v1.24.417.1+ Causes error "The WMI service or the WMI provider returned an unknown error: HRESULT 0x80041033" on Exchange workload

[jadamones]

Description of the issue

Getting this error when testing Exchange workloads on all ADO agents using the testcompliance.ps1 script or running Test-DSCConfiguration on any machine after updating to version '1.24.424.1'.

Switching back to version 1.24.403.1 and swapping resources affected by breaking changes back seems to resolve the issue. I attempted to debug but it's cumbersome and it seems to fail randomly and not on a specific resource.

I'm getting these errors in the event log when it happens.

Application: wmiprvse.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.OutOfMemoryException

Microsoft 365 DSC Version

1.24.424.1

Which workloads are affected

Exchange Online

The DSC configuration

No response

Verbose logs showing the problem

.
2024-05-03T12:42:13.3553564Z VERBOSE: [dsc-operator01]:                            [[EXORoleGroup]EXORoleGroup-Security 
2024-05-03T12:42:13.3558704Z Reader::[Exchange]Exchange_Configuration] Getting Role Group configuration for Security Reader
.
.
.
2024-05-03T12:42:15.9457247Z :x: False | 999 | The WS-Management service cannot process the request. The WMI service or the WMI provider returned an unknown error: HRESULT 0x80041033

Environment Information + PowerShell Version

OsName               : Microsoft Windows 11 Enterprise
OsOperatingSystemSKU : EnterpriseEdition
OsArchitecture       : 64-bit
WindowsVersion       : 2009
WindowsBuildLabEx    : 22621.1.amd64fre.ni_release.220506-1250
OsLanguage           : en-US
OsMuiLanguages       : {en-US}

Name                           Value
----                           -----
PSVersion                      5.1.22621.2506
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.22621.2506
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

[todde99]

I'm facing the same issue here (Microsoft365DSC 1.24.515.2). When running Start-DSCConfiguration -Path ... -Wait -Verbose -Force for the resource ExchangeOnline and I'm having more than two EXO components configured, it stops after around 10 minutes with the error message:

NativeErrorCode : Failed
ErrorData       : MSFT_ExtendedStatus
MessageId       : HRESULT 0x80041033
ErrorSource     :
ErrorType       : 0
StatusCode      : 0
Message         : The WS-Management service cannot process the request. The WMI service or the WMI provider returned an unknown error: HRESULT 0x80041033
Data            : {}
InnerException  :
TargetSite      : Void ProcessNativeCallback(Microsoft.Management.Infrastructure.Native.OperationCallbackProcessingContext, T, Boolean,
                  Microsoft.Management.Infrastructure.Native.MiResult, System.String, Microsoft.Management.Infrastructure.Native.InstanceHandle)
StackTrace      :    at
                  Microsoft.Management.Infrastructure.Internal.Operations.CimAsyncObserverProxyBase`1.ProcessNativeCallback(OperationCallbackProcessingContext
                  callbackProcessingContext, T currentItem, Boolean moreResults, MiResult operationResult, String errorMessage, InstanceHandle
                  errorDetailsHandle)
HelpLink        :
Source          : Microsoft.Management.Infrastructure
HResult         : -2146233088

Also the application event:

Log Name:      Application
Source:        Application Error
Event ID:      1000
Task Category: (100)
Level:         Error
Description:
Faulting application name: wmiprvse.exe, version: 10.0.20348.1, time stamp: 0xda796ffd
Faulting module name: clr.dll, version: 4.8.4718.0, time stamp: 0x65f23849
Exception code: 0xc00000fd
Fault offset: 0x0000000000090fd4
Faulting process id: 0x3cd8
Faulting application start time: 0x01daa79c097e380b
Faulting application path: C:\Windows\system32\wbem\wmiprvse.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Report Id: 75d73076-9e9a-45c6-bc4f-cbe24764d5e6

Running on

OS Name:                   Microsoft Windows Server 2022 Standard
OS Version:                10.0.20348 N/A Build 20348

Name                           Value
----                           -----
PSVersion                      5.1.20348.2400
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.20348.2400
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

[ricmestre]

@NikCharlebois @andikrueger I've also hit this issue while running my test harness locally, it went through applying almost all resources included in the EXO, Intune, O365, OD, SP and Teams workloads to my test tenant (this step didn't cause any issues) but then it's programmed to call Test-DSCConfiguration on all of those resources and eventually failed the test on EXOSafeAttachmentPolicy, it worked for other EXO resources before so I don't know why this is happening.

[tayhall]

I also have this issue, especially if trying to run the resource on a container. Ive tried increasing the RAM to 8gb but it seems to fail every time. The RAM usage for WMI on my PC increases dramatically (1Gb to over 3Gb), maybe its not releasing resources or handles between workloads or the additional item logging is pushing it too far?

Microsoft365DSC = '1.23.1220.1' - No WMI issues and ADO Green ticks 100% of the time
#Microsoft365DSC = '1.24.417.1' - WMI errors usually on the Security and Compliance module with the unknown HRESULT 0x80041033
#Microsoft365DSC = '1.24.612.1' - WMI errors usually on the Security and Compliance module with the unknown HRESULT 0x80041033

I have tried increasing some of the WMI parameters in WSMAN: but to no avail. This is a big issue given it affects DSC versions for months IMO.

[jadamones]

@ricmestre and @andikrueger I'm still having this issue on the compliance test. I just updated to '1.24.724.1'. One environment gets "The WS-Management service cannot process the request. The WMI service or the WMI provider returned an unknown error: HRESULT 0x80041033" and the other gets "Exception of type 'System.OutOfMemoryException' was thrown."

Reverting to v 1.24.403.1 resolves both issues. Any insights on how to resolve?

[jadamones]

@tayhall did you ever resolve this?

[tayhall]

No the only solution was to just apply config by workloads and retry when exchange had its issues.

…

On Wed, 14 Aug 2024, 20:52 jadamones, ***@***.***> wrote: @tayhall <https://github.com/tayhall> did you ever resolve this? — Reply to this email directly, view it on GitHub <#4632 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMKOMXH6TGRKN75EMOQBUHTZRORN5AVCNFSM6AAAAABHFQ7XJKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBZGU4TQMJTG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[JbMachtMuschel]

I have the same issue, trying to import more than 400 activesyncdeviceaccessrules and it is failing after 42 imported rules.
Importing in a test-tenant, using certificate based authentication.
Powershell version 5.1
Run following commands:
Update-M365DSCDependencies
import-Module Microsoft365Dsc
$Component = "EXOActiveSyncDeviceAccessRule"
update-M365DSCAllowedGraphScopes -ResourceNameList @($Component)
Set-Item -Path WSMan:\localhost\MaxEnvelopeSizekb -Value 8192 #without this, is is failing almost immediately
Start-DscConfiguration -Path C:\DscCert\Cert20240731\EXOActiveSyncDeviceAccessRule20240730_175209M365TenantConfig -Wait -Verbose -Force

Errors:
The WS-Management service cannot process the request. The WMI service or the WMI provider returned an unknown error: HRESULT 0x80041033
+ CategoryInfo : ResourceUnavailable: (root/Microsoft/...gurationManager:String) [], CimException
+ FullyQualifiedErrorId : HRESULT 0x80041033
+ PSComputerName : localhost

AppLog:
EventID: 1000
Faulting application name: wmiprvse.exe, version: 10.0.17763.1, time stamp: 0xdd9b741c
Faulting module name: ntdll.dll, version: 10.0.17763.5933, time stamp: 0x28f68183
Exception code: 0xc00000fd
Fault offset: 0x00000000000a4f27
Faulting process id: 0x39d4
Faulting application start time: 0x01daf31d76de805b
Faulting application path: C:\Windows\system32\wbem\wmiprvse.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: f09878ae-ba24-4c8a-aa9d-0163cf04ef8f
Faulting package full name:
Faulting package-relative application ID:

[jadamones]

The workaround to this is increasing the WMI Provider host quotas as mentioned in #4982