Powershell Universal Service keeps stopping

Hi @jdietz,

Please collect a dump the next time the PowerShell Universal service stops unexpectedly. Run the following in an elevated PowerShell prompt:

New-Item -ItemType Directory -Path C:\PSUDumps -Force

$dumpKey = 'HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\Universal.Server.exe'
New-Item -Path $dumpKey -Force | Out-Null
New-ItemProperty -Path $dumpKey -Name DumpFolder -PropertyType ExpandString -Value 'C:\PSUDumps' -Force
New-ItemProperty -Path $dumpKey -Name DumpType -PropertyType DWord -Value 2 -Force
New-ItemProperty -Path $dumpKey -Name DumpCount -PropertyType DWord -Value 3 -Force

This enables up to three full crash dumps for Universal.Server.exe. Once the service stops again, please securely provide:

1. The newest .dmp file from C:\PSUDumps
2. %ProgramData%\PowerShellUniversal\Logs\System\systemLog.txt
3. Windows Application Event Log entries from the same time period

A full dump can contain sensitive data, so please do not attach it to a public forum post. If you could please email service@devolutions.net and ask for a folder to upload the memory dump, they will be able to provide it and I can analyze it.

Files are uploaded

Hey @jdietz ,

This appears to be an issue with the Microsoft Configuration Manager PowerShell console module causing a stack overflow exception within the PowerShell Universal server.

It's recursively calling this stack trace.

`AdminUI.PS.dll` → `CMPSCmdlet.GetSiteOperationalDetails` → `LogAdhocBug` → `ReportAdhocBug` → `GetOperationalDetails` → `GetSiteOperationalDetails`

It was loaded from:

C:\Program Files (x86)\Microsoft Configuration Manager\AdminConsole\bin\AdminUI.PS.dll

It appears that the assembly is attempting to perform error reporting, but the original exception wasn't included in the dump or event log entry. Because of that, I don't know root cause exactly. If you are using this module in your PowerShell scripts within PSU, I would recommend that you isolate it in a subprocess rather than running it within the integrated environment. This will prevent it from completely crashing the server. When configuring your scripts, you can set the environment to something like PowerShell 7 or Windows PowerShell 5.1, rather than Integrated or Default, if you haven't adjusted your default environment value.

If you cannot access PowerShell Universal due to this, you can always edit the scripts and configuration files in %ProgramData%\UniversalAutomation\Repository and then adjusting it to avoid loading the module until we can sort out why it causes PSU to crash.

If you could get the current version of the module in PowerShell, that would be helpful. You can run the following in a PowerShell terminal on the server to find out that information.

Get-Module -Name *Admin* -ListAvailable

Adam,

I assume you wanted the SCCM module version.

Get-Module -Name *Admin* -ListAvailable did not show me this and same with Get-Module -Name ConfigurationManager

The module should be version 5.2603.1035.1000. I am on the latest SCCM current branch of 2603 w/ hotfix installed.

I did uninstall the Configuration Manager console from the server and this appears to have stopped the issue.

However, I am attempting to move all my jobs off System Center Orchestrator to Powershell Universal and automating a lot of SCCM is done there.

Let me know what other information you need to hopefully fix this and I can then reinstall the Admin Console. If a call / screenshare is needed just email me.

Hello Justin,

Thanks for the logs, they lined up exactly with Adam's dump analysis from the forum.

I want to walk you through what the logs show, why the workaround Adam suggested is the right fix, and the exact steps to apply it.

The Application event log has three APPCRASH records in the window you shared, all with exception code 0xC00000FD (stack overflow).

The fault module rotates between ntdll.dll and coreclr.dll, which is the same class of failure just observed from different frames.

I cross-referenced each crash against the PowerShell Universal system log you uploaded.

Every one of the crashes fires within a few seconds after one of your scheduled jobs starts in the Integrated environment.

That is the pattern for the whole file: your two schedules run every couple of minutes each in Integrated, and none of them ever emit a completion line, they just crash the service.

That aligns exactly with the recursive call in the Configuration Manager cmdlets that Adam found in the dump (AdminUI.PS.dll, GetSiteOperationalDetails calling ReportAdhocBug calling itself).

When a script imports the Configuration Manager module in the Integrated environment, the module is loaded inside the Universal.Server.exe process.

When it hits a stack overflow, the whole service goes down.

The August Windows Server 2025 cumulative update refreshed ntdll.dll, and the new build ends stack overflow situations by fail-fasting the process.

The recursion was there before the update; the update made it always fatal.

The clean fix is to move the two scripts off the Integrated environment onto a non-integrated one that spins up a child powershell.exe.

When the SCCM cmdlets crash they take only the child job with them, not the PowerShell Universal service.

Concretely:

In the admin console, open Platform, then Environments, then Add. Name it WinPS51, path powershell.exe. Save. That is your Windows PowerShell 5.1 environment. Windows PowerShell 5.1 is the version the Configuration Manager module officially targets and it is the safest starting point.

In the admin console, find the two schedules that are firing today. Pause them, then open each of the underlying scripts and change the Environment field to WinPS51.

In each script, import the Configuration Manager module from the path pointed to by the SMS_ADMIN_UI_PATH environment variable, then create the CMSite PSDrive for your site code against your SMS provider FQDN (only if that drive is not already present), and finally set the location to that site drive. This is the same sequence the Configuration Manager console shortcut runs at startup.

Restart the PowerShell Universal service once, then re-enable both schedules. Watch C:\ProgramData\PowerShellUniversal\Logs\System\systemLog<date>.txt. You want to see Job xxx completed lines and no more APPCRASH events in the Application log. If a Configuration Manager cmdlet still misbehaves in that mode, please share the exact call and the error and we will look at the next step from there.

Two side notes I noticed in the logs while I was in there.

Neither is related to the crash, only cosmetic.

Kestrel logs a warning that HTTP/2 is not enabled on the plain HTTP endpoint.

That is normal because HTTP/2 needs TLS. Ignore.

The system log also has repeated CORS policy execution failed lines against the origin you browse from.

Adding that origin to CorsHosts in appsettings.json and restarting will silence that.

Let me know how the non-integrated environment behaves once you re-enable the two schedules.

Best regards,

Patrick,

I appreciate the response. I probably will not have time to work through this until next week.

One thing from what you wrote however was about the jobs being "scheduled". The scripts I have that called the MCM module were not scheduled. They were being tested and ran on demand. Even after restarting the service and rebooting the Powershell Universal server......the service would crash without me running that script.

I do agree the MCM module was doing this. I have removed the console / module from the server for now and I am looking for a way to work around it.

Hello,

Thanks, and take next week without pressure.


That actually simplifies things, because the goal is now clear: keep AdminUI.PS.dll out of the Universal.Server.exe process entirely, while still being able to automate SCCM from PowerShell Universal.

Three ways to get there, from most to least isolated.

Run the Configuration Manager cmdlets on your SCCM site server, or any admin box that has the console, over PowerShell Remoting from PSU.
Store the service account credential in a PSU secret and variable.

In your script, open a session with New-PSSession -ComputerName <sccm-primary> -Credential $cred, then run your CM logic inside an Invoke-Command -Session block that imports the module from $env:SMS_ADMIN_UI_PATH and does its work.

The console module is loaded in the remote powershell.exe on the site server, never in the PSU host, so even if it hits the same recursion it only kills that one remote session.

This is the cleanest option and the one I would lead with, especially since your site server already has the console and PowerShell remoting configured for other admin tooling.

Skip the module entirely and call the ConfigMgr Administration Service REST API, which is what modern SCCM (1810 and later) exposes for exactly this kind of automation.
Base URL pattern: https://<SMSProvider>/AdminService/wmi/SMS_R_System and similar collections.

Invoke-RestMethod from any PSU environment covers the vast majority of what you would use the module for, with zero dependency on AdminUI.PS.dll.

Good option if you would rather not stand up remoting, or if you want the automation to be independent of console version and PowerShell edition.

Keep the console on the PSU host but never expose it to the Integrated environment.
Create a dedicated Windows PowerShell 5.1 environment for SCCM only, and constrain its module path so it does not resolve Microsoft Configuration Manager\AdminConsole\bin.

I list this only as a fallback, because your data point that the crash happened with no script invocation means something in your install was pulling the DLL in on its own, and I have not proven what that was.

Best regards,

Hello,

Thank you for your time during this session.

You mentioned that this issue is resolved.
Since it is resolved, I will close this thread.

Best regards,