I manage a small fleet of about 200 desktops. I’ve been running into an issue where remote desktop stops working on some of them until I reboot the machine. Most of them are headless, so it’s been tough to narrow down the issue.

I picked out one and hooked it up to a monitor and it finally broke for me, this is the error I see:

“LogonUI.exe - System Error”

“The process has terminated because it could not allocate additional memory.”

While I have the machine in this state, I’m trying to find out what I can about it remotely before I reboot it. Based on the error I checked the amount of physical memory in use, but it was less than 30%. However, nearly all of the virtual memory is in use (only 21MB free out of 65GB).

Normally I run a tool like RAM map to see what’s hogging the memory but I’m not sure how to find that info out remotely.

Anyone come across something similar? I’m wanting to see if one of the applications running on the system is causing this.

3 Spice ups

It’s possible there is a memory leak, but if you’re getting errors with applications, start by looking at the event logs and gathering soe info.

It might also help us, to help you if you note the spec of these devices, with 65GB of swap, I’m expecting 16GB or 32GB of memory, otherwise there is a bigger issue if swap is that size.

What OS and applications do these machines run?

2 Spice ups

Yes the hosts typically have 16-32GB of memory. They’re all running Windows 10 1809 LTSC enterprise.

They’re running crowdstrike for AV and a number of debugging tools.

As a test, I’m going to try disabling the paging file on this one particular host since no one is using it. Maybe I can gain some insights that way.

1 Spice up

You should still have event logs from previous. If you can grab one of those it may help us.

1 Spice up

I don’t think I can share the event logs themselves, too much proprietary info.

This appears to be when the logonui crashed:

Faulting application name: LogonUI.exe, version: 10.0.17763.1, time stamp: 0x5ab44f80
Faulting module name: Windows.UI.Xaml.dll, version: 10.0.17763.7009, time stamp: 0x01df9dee
Exception code: 0xc000027b
Fault offset: 0x00000000004c8646
Faulting process id: 0x1114
Faulting application start time: 0x01db9b22adc27364
Faulting application path: C:\WINDOWS\system32\LogonUI.exe
Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll
Report Id: ab06afb0-60c3-4c46-9434-df7c66861ea5
Faulting package full name:
Faulting package-relative application ID:

Also seeing several places in the system log about the paging file:

The Group Policy Client service failed to start due to the following error:
The paging file is too small for this operation to complete.

Not just the Group Policy Client but several other services.

1 Spice up

That’s fine, I wasn’t looking to see them all.

Windows.UI.Xaml.dll this is your issue, but it’s cause could be corrupt OS, corrupt user profile, bad update, conflicting software.

You’ll need to see what other apps you have that may interact with the login screen, any personalization any adjustments to the default etc.

Of not try running sfc /scannow

As far as your page file, set it to system managed or at least double your ram, 3x is the usual.

While you don’t want the page file to be used, if it’s not there or too small, it can also cause the issue you see above.

Sounds like a memory leak. Use the following PowerShell command to what process is using the most virtual memory:

Get-Process | Select Name, Id, PagedMemorySize64, Description | Where PagedMemorySize64 -gt 100MB | Sort PagedMemorySize64

Paging file is usually limited to 3×RAM and 1/8 of volume size – 64GB limit could be more reflective of 512GB drive size instead of the RAM limit. System managed increases the paging file size each time reaches 90% commit charge.

If it’s a Kernel-mode driver then it’s more difficult to identify which one is causing. Check the Windows Update history for any recent driver updates.

OK, I finally got this system to reproduce this error with the paging file disabled. It is sitting at 98% memory usage. I’m logged in locally but it’s totally unresponsive, so I’m trying to see if I can remotely determine what process is using up all of the ram. I’ve tried “remote process explorer” as well as tasklist, but neither of them is showing anything using up anywhere near that much memory.

Nothing in the process list seems to be using much memory:
image

When I open task manager, the process list fails to load and it just shows memory at 97-98%

Looks like I found what’s actually going on. As suspected, there appears to be a memory leak. In this case there are 3 or 4 different processes that appear to be experiencing abnormally high memory usage. Unfortunately, they’re all business critical. So I’m going to have to work with the lab compute team. Either way, marking this resolved.

1 Spice up