Windows 10 Home / "x64-based PC" / Dell XPS 13 9360
In Reliability Monitor, I have many "app failures" every day. They go back all the way to 2017-12-04 without variation (the details below are identical), when I believe this machine was first used. The problem is marked as having been reported (apart from problem instances in the past few minutes).
@magicandre1981 also suggested I open a public problem in the Windows app Feedback Hub for some reason.
My question is: How can I identify this? What causes the crashes? Can they be resolved somehow?
"Anti-virus" is installed (McAfee VirusSafe) and running with no alerts, no quarantined items, no significant logs that I can find.
sfc /scannow gives the system a clean bill of health.
It seems possible to trigger the crash by logging in. This isn't what has been causing it in the past, because the machine doesn't usually have a user logging in and out (or even turning the machine on and off).
Process Monitor allows to trace process creation and exit. Running it as a second user, I am able to see the crashing process:
"C:\WINDOWS\system32\rundll32.exe" -localserver 22d8c27b-47a1-48d1-ad08-7da7abd79617.
It's not really clear what this UUID is. The
-localserver option does not appear to be documented. Google finds a question, the only answer claims it is "Process Profiling Performance Analysis Program (Windows Performance Counter Program)". Admittedly I can see that
powrprof.dll are loaded in this process.
Described as "I don't feel good about this code, so I'm going to ask COM to host it in another process. That way, if it crashes, it's the COM Surrogate sacrificial process that crashes instead of me".
This UUID in the parent's command line can be found in the registry. It is associated with the name "Shell Create Object Task Server". Using the registry tracking in Process Monitor, I see
shell32.dll, located via
=> I think we can identify this parent process, as shell32.dll / "Shell Create Object Task Server", and that it is part of the OS.
Both processes run as the user
NT AUTHORITY\SYSTEM. This seems a possible venue of investigation. What is the privileged part of the GUI software doing, that needs to be run in a separate process?
procdump -ma -i C:\dumps, I am able to capture crash dumps. (
procdump -u to stop capturing). The analyzer from DebugDiag is able to open them and run the CrashHangAnalysis:
In rundll32.exe_171225_165805.dmp the assembly instruction at Windows_UI_Immersive!CUserTileValidator::_SetReadOnlyCapability+1d in C:\Windows\System32\Windows.UI.Immersive.dll from Microsoft Corporation has caused an access violation exception (0xC0000005) when trying to read from memory location 0x00000000 on thread 0.
The following threads in
rundll32.exe_171225_165805.dmpare processing an inbound RPC call over LRPC to the
( 0 )
Thread 0 - System ID 4332
- Entry point rundll32!wWinMainCRTStartup
- Create time 25/12/2017 16:58:04
- Time spent in user mode 0 Days 00:00:00.000
- Time spent in kernel mode 0 Days 00:00:00.000
ntdll!NtWaitForMultipleObjects+14 ntdll!WerpWaitForCrashReporting+a8 ntdll!RtlReportExceptionHelper+33e ntdll!RtlReportException+9d combase!ServerExceptionFilter+71 combase!AppInvokeExceptionFilterWithMethodAddress+62 combase!`ObjectMethodExceptionHandlingAction<<lambda_76d9e92c799d246a4afbe64a2bf5673d> >'::`1'::filt$0+77 ucrtbase!_C_specific_handler+a0 ntdll!RtlpExecuteHandlerForException+d ntdll!RtlDispatchException+358 ntdll!KiUserExceptionDispatch+2e Windows_UI_Immersive!CUserTileValidator::_SetReadOnlyCapability+1d Windows_UI_Immersive!CUserTileValidator::_GenerateLargeFromDynamicAndReset+23 Windows_UI_Immersive!CUserTileValidator::ValidateUserTile+141 rpcrt4!Invoke+73 rpcrt4!NdrStubCall2+3a5 rpcrt4!NdrStubCall3+e3 combase!CStdStubBuffer_Invoke+62 rpcrt4!CStdStubBuffer_Invoke+3b combase!ObjectMethodExceptionHandlingAction<<lambda_76d9e92c799d246a4afbe64a2bf5673d> >+53 combase!DefaultStubInvoke+2d2 combase!ServerCall::ContextInvoke+492 combase!AppInvoke+99e combase!ComInvokeWithLockAndIPID+55b combase!ComInvoke+210 combase!ThreadDispatch+d4 combase!ThreadWndProc+e8 user32!UserCallWinProcCheckWow+2ad user32!DispatchMessageWorker+19f rundll32!_InvokeLocalServer+1b9 rundll32!wWinMain+168 rundll32!operator delete+2eb kernel32!BaseThreadInitThunk+14 ntdll!RtlUserThreadStart+21
Inbound RPC Call: Protocol Sequence ncalrpc Endpoint OLE54BFB094974A828ACE9FBFE5A353 Source Process ID 1160 Source Thread ID 2624
PID 1160 is an svchost.exe instance for "RPC" and "RPC Endpoint Mapper", according to Process Explorer.
Apparently, the crashes are caused by validating the
UserTile of this specific user.
I believe this refers to the picture that is shown when you log in. After setting the user's picture to an arbitrary image file taken from
Pictures/, the crash was no longer triggered when I go to switch users and log in as the specific user.
It looks like "Exception offset" is a code offset inside the DLL/EXE (i.e. avoiding the effect of relocation / address randomization). So the crash location can be identified by "Exception offset" + the specific DLL/EXE contents -
If you have debugging symbols for the DLL/EXE, you may be able to take extra effort to look up this location. Use
procdump as described to capture a crash dump. Open the dump with any debugger which supports the Microsoft Symbol Service, if the DLL/EXE is from Microsoft. The names of the symbols are less likely to change over time (or different hardware platforms) than the numeric addresses. A debugger will also show a full trace of the nested function calls leading to the crash.
User contributions licensed under CC BY-SA 3.0