PSSCor2: Miscellaneous Commands

Previously, we’ve seen how PSSCor2 enhances the GC heap analysis experience. In this final installment, we’ll look at some additional commands that I couldn’t group together with anything else.

One awesome SOS command that you should be familiar with is !SaveModule. This command takes a module address from a dump file and saves the result to a DLL (or EXE) that you can open with Reflector or ILDASM. It means that even if you don’t have the original assemblies, you can use a full dump to extract them to disk and open them. PSSCor2 introduces the !SaveAllModules command, a natural extension that saves all modules from the dump file to a directory of your choice.

Another neat command, !DumpAllExceptions, displays all managed exception objects present on the heap. Note that not all exception objects represent an actual exception that’s currently in flight—someone might create an instance of an exception and stow it away to throw it later. This is exactly what the CLR does for certain “tough” exceptions, which explains the following output on an empty console app:

0:003> !dumpallexceptions
Going to dump the .NET Exceptions found in the heap.
Loading the heap objects into our cache.
Number of exceptions of this type:        1
Exception MethodTable: 70540e2c
Exception object: 024010b4
Exception type: System.ExecutionEngineException
Message: <none>
InnerException: <none>
StackTrace (generated):
<none>
StackTraceString: <none>
HResult: 80131506
The current thread is unmanaged
-----------------

Number of exceptions of this type:        1
Exception MethodTable: 70540d9c
Exception object: 0240106c
Exception type: System.StackOverflowException
Message: <none>
InnerException: <none>
StackTrace (generated):
<none>
StackTraceString: <none>
HResult: 800703e9
The current thread is unmanaged
-----------------

Number of exceptions of this type:        1
Exception MethodTable: 70540d0c
Exception object: 02401024
Exception type: System.OutOfMemoryException
Message: <none>
InnerException: <none>
StackTrace (generated):
<none>
StackTraceString: <none>
HResult: 8007000e
The current thread is unmanaged
-----------------

Number of exceptions of this type:        2
Exception MethodTable: 70540ebc
Exception object: 024010fc
Exception type: System.Threading.ThreadAbortException
Message: <none>
InnerException: <none>
StackTrace (generated):
<none>
StackTraceString: <none>
HResult: 80131530
The current thread is unmanaged
-----------------

Total 5 exceptions

Next, the !DumpRuntimeTypes command displays all the types on the heap along with their method table address. This is useful if you want to look at types that don’t have any instances, so you won’t see their instances in the standard !dumpheap output.

And last but not least, there are an additional four commands that I’ll leave for you to explore on your own:

• !DumpDynamicAssemblies displays and optionally saves all the assemblies that were dynamically created
• !FindDebugTrue and !FindDebugTrueModules displays AppDomains and modules that have debug=true in their web configuration
• !Analysis runs a slew of useful commands on a dump file, streamlining the analysis process (it enumerates all threads, checks the state of the thread pool, displays thread stacks, dumps sync blocks, shows all AppDomains, analyzes GC memory usage, and lots of other stuff)

That’s roughly it. In the four posts on PSSCor2, I gave you a whirlwind tour of fairly useful functionality that you can start using with your CLR 2.0 applications today. It’s a download away, unlike SOS, but it might be worth your while.

What Did My Manifest Do: A Referral Was Returned from the Server

The UAC section of an application’s manifest contains two simple settings under the <requestedExecutionLevel> element of the <requestedPrivileges> node:

• level – asInvoker, requireAdministrator, or highestAvailable. This setting controls whether the application will require elevation before it runs.
• uiAccess – true or false. This setting determines whether the application will exempt from UIPI rules introduced as part of the Windows Integrity Mechanism.

If you really need the uiAccess element (and you should be really convinced that you understand why you need it before proceeding), then your application must be signed, and by default, must reside in one of the secure locations, namely \Program Files, \Windows\system32, or \Program Files (x86).

This latter setting can be changed through group policy (see the screenshot below), but there’s no way to circumvent the certificate verification.

If your application doesn’t comply with these requirements but the manifest still contains the uiAccess=true setting, your process will fail to launch with the cryptic “A referral was returned from the server” error message:

This isn’t the friendliest way of saying that there’s something wrong with your UAC manifest setting, but that’s why I’m writing this post.