I saw this process on Windows 10, processing User Tiles - more commonly known as User Account Pictures. Possibly it is used to process other types of untrusted user data; I don't know.
The code is part of the Windows "shell" (desktop interface) package, and the process is running as the user "NT Authority/SYSTEM". I think this means it is part of the login / "fast user switching" interface. The behaviour I observed is all down to Windows. I was specifically looking out for any (buggy) third-party code, and I did not find anything suspicious.
Windows Rundll32 (child process of DllHost) is crashing. How can I even identify it?
I captured a stack trace of thread 0, while it processed an incoming COM request. It shows a class
Windows_UI_Immersive!CUserTileValidator. I was capturing this trace as the process was crashing, when it processed the picture. In my mental model, this is a sandboxed process that decompresses the user picture, but I expect a precise description would be more complex.
The issue was specific to one user: I was able to reproduce the crash by locking my session and logging in as this specific user, but not the other way round. The user's profile picture was displayed as the default icon. Changing the user's profile picture stopped the crashes.
I cannot find documentation for the
-localserver option of Rundll32. As per other commenters, the UUID value cannot be found anywhere in the registry. I don't know how Rundll32 looks up this value! The term LocalServer is used elsewhere when talking about a command used to launch a dedicated COM server process. (Often
DllHost.exe, as mentioned below).
The Rundll32 process had a parent process, an instance of
DllHost.exe ("COM Surrogate"). Looking at the command line of the DllHost, the
/ProcessID parameter was an AppID listed in the registry as "Shell Create Object Task Server", from shell32.dll. Both processes ran as "NT Authority/SYSTEM".
In some sense, the crashes I saw were anticipated. DllHost.exe was designed to run unreliable COM objects. Apparently this was within a user session. My link doesn't comment on don't know how well it protects insecure COM objects; a particular concern when run as SYSTEM.