Microsoft / Sysinternals Process Monitor

Microsoft / Sysinternals recently released a new tool named "Process Monitor" (that Mark Russinovich has talked about for over a year). Process Monitor blows FileMon and RegMon (great tools in their own rite) out of the water with a well thought out filtering mechanism and NON DESTRUCTIVE filters! Filtering data no longer destroys the original! Now, since all events are captured, the amount of disk space required to store the events can grow quickly - it's easy to get a few GB of data in a short amount of time - but the data can be captured and stored for later analysis. There are plenty of other features in Process Monitor including the ability to get the FULL stack (userland and kernel!) of a thread at the time of an event, the ability to organize and persist filter sets, highlighting, and more. Thanks Mark & Bryce / Microsoft!

Note that Process Monitor does require a "modern" operating system - Windows XP SP2 or later, Windows Server 2003 SP1, Windows 2000 SP4 with Update Rollup 1, Vista, and x64 versions of XP, Server 2003 SP1, and Vista. Some people have issues with this, but the requirements are not arbitrary. Bryce explains a bit here.

»

Microsoft Vista and Application Compatibility

There's an article entitled "Inside the New Microsoft Application Compatibility Toolkit" on TechNet that (surprise!) discusses some things about compatibility of applications running on Vista. It provides a good overview of some of the changes that can affect compatibility and some of the progress that has been made with Vista. For example, Windows Resource Protection redirects / sandboxes file and registry accesses to resources that the app wouldn't generally have permissions to when run under a standard account. The changes aren't persisted across invocations of the application, but nonetheless it could enable apps to work under a standard account when they previously were "admin or bust".

The article also discusses how to go about analyzing the applications running on one's computers and assessing the compatibility impact. There is a central database of applications called the "Microsoft Compatibility Exchange" which contains information provided by other community members about the compatibility "levels" of various applications. I like the idea of leveraging community experiences for the benefit of all.

The "Application Compatibility Toolkit" has other capabilities that are touched on in the article and are described in more detail in the documentation that accompanies the toolkit and at the Windows Application Compatibility website.

»

Physician, Heal Thyself

I was working on a system that was suspected of being infested with malware. Sadly, it was clean - the flakiness was caused by all of the security utilities and software that had been installed on the system. But that's a rant for a different day. In the process of dealing with the system, an application crashed. I don't recall specifically what it was, but whilst gathering information about the crash, Dr. Watson had some problems himself. The good doctor just couldn't cope, apparently.

I cracked open Process Explorer and looked at the process hierarchy. It seemed a bit odd to have Dr. Watson spawn Dr. Watson (drwtsn32.exe was the parent of drwtsn32.exe).

I love the standard wording: "DrWatson Postmortem Debugger has encountered a problem and needs to close. We are sorry for the inconvenience."

I think in this case I chose to send the error report to Microsoft. =8->

»

Key Containers and Visual Studio 2005: What's Microsoft Trying To Say?

As noted in Signing Assemblies in Visual Studio 2005 with Key Containers, Visual Studio 2005 doesn't exactly deal well with key containers (there's no way to use the UI to specify one, as one can do with key files).

And when I was exploring Web Deployment Projects, I was reviewing "Managing ASP.NET Precompiled Output for Deployment Using the aspnet_merge.exe Command" (aspnet_merge.exe is used by Web Deployment Projects to combine the assemblies produced by aspnet_compiler.exe). That article states that "...you can use the following options with aspnet_merge.exe: -keyfile, -keyContainer, or -delaysign...". I'm a strong advocate of signing assemblies. While there may not be a strong (ha, ha) case for doing it in this instance, it at least provides some level of assurance that the code deployed is truly the code that is supposed to be running. And I prefer key containers to key files. So given the way that specifying a key container works in Visual Studio 2005, I was excited to see that aspnet_merge.exe supported key containers.

Then I checked out the Web Deployment Project property pages. The Signing tab had a place to specify a key file location, but no way to specify a key container.



Argh! Here we go again, I thought. So I went about the process of trying to tear up the .WDPROJ file that is the Visual Studio 2005 project file for Web Deployment Projects. I tried the same technique that worked for .CSPROJ files, but that didn't work. I checked Microsoft.WebDeployment.targets in %programfiles%\MSBuild\Microsoft\WebDeployment\v8.0 to see if there was some way to specify a key container there. I couldn't find anything for key containers, but there were certainly ways to specify a key file and that the merged assembly should be delay signed. Dead end there.

Next I cracked open Reflector and inspected Microsoft.WebDeployment.Tasks.dll (also from %programfiles%\MSBuild\Microsoft\WebDeployment\v8.0). In that assembly, there is a class named "AspNetMerge" that implements the merge task as instructed by MSBuild. (The class inherits from Microsoft.Build.Utilities.ToolTask.) The "AspNetMerge" class has the following private fields (as reported by Reflector):

    private string _applicationPath;
    private string _assemblyInfo;
    private string _contentAssemblyName;
    private bool _copyAttributes;
    private bool _debug;
    private bool _delaySign;
    private bool _errorStack;
    private string _exePath;
    private string _keyFile;
    private string _logErrorFile;
    private bool _mergeXmlDocs;
    private bool _nologo;
    private string _prefix;
    private bool _removeCompiledFiles;
    private string _singleAssemblyName

Sigh. A setting for a key container name is nowhere to be found. If the tool doesn't support key containers, no amount of creative configuration will get it there.

The next thing I did, in retrospect, was probably the first thing I should have done:

aspnet_merge -?

In short, aspnet_merge only supports the following parameters:

• -?
• applicationPath
• -keyfile
• -delaysign
• -o
• -w
• -prefix
• -copyattrs
• -debug
• -nologo
• -errorstack
• -r
• -xmldocs
• -a
• -log

Aspnet_merge.exe does NOT support the -keycontainer option, as the "Managing ASP.NET Precompiled Output for Deployment Using the aspnet_merge.exe Command" article had stated.

So, given that there's no way to use a Web Deployment Project / aspnet_merge.exe to use a key container to sign an assembly, and one needs to edit the raw .CSPROJ file to get VS2005 to use a key container to sign an assembly, it seems that Microsoft is trying to say something about key containers.

I wouldn't be surprised to see key containers completely dropped in Orcas...

Deploying ASP.NET 2.0 Applications

I was recently exploring deployment options for ASP.NET applications and I encountered a couple of Visual Studio 2005 add-ons - Visual Studio 2005 Web Deployment Projects and Visual Studio 2005 Web Application Projects. I could go into some detail about each of these post-Visual Studio 2005 release features, but Rick Strahl's got it covered with an extensive article entitled Compilation and Deployment in ASP.NET 2.0.

Visual Studio 2005 Web Application Projects bring ASP.NET 1.x style deployment capabilities (website compiles to an assembly at build time for later deployment with the display-side components compiled when accessed at runtime). Visual Studio 2005 Web Deployment Projects allow one to manage web application build configuration and deployment options, and provide a tool to merge multiple assemblies into one. This allows one to, if desired and configured, deploy a web application rolled up into one assembly and a number of "marker" files. Display-side components can even be compiled into the assembly. Note that other assemblies that the web application depends on - such as assemblies from the Enterprise Library - and other resource files such as images also need to be deployed. One could potentially use ILMerge (here and here) to merge all required assemblies into one, if that was important.

I really like the idea of minimizing the number of files that need to be deployed to a web server so I hope to work with Web Deployment Projects and Web Application Projects more in the future.

Determining System Uptime, and A Bit More

I'm probably being way too picky here.

A new Community Solutions article in the Microsoft Knowledge Base entitled How to find Windows uptime? has been posted. The article is short (four steps and a summary for Option 1), but from my perspective this short article has a couple of errors, and / or at least could be a bit clearer.

While I know what is meant by uptime (how long the computer has been "up" or running), someone looking for this information may not know that's what to call it or what it might mean, so in the event they are able to find the article they may gloss over it because they don't recognize the term. Perhaps a brief description of what is meant by "uptime" in the context of this article would be appropriate.

Further, the steps detailed in the article (basically, instructions on how to run a command - net statistics server - and then parse the output) don't provide one with the information the article indicates will be provided. Granted, this is likely an academic detail, but the command really displays the amount of time that the Server service has been running - not the amount of time that the computer has been up. It is possible (but admittedly not all that likely) that the Server service has been restarted since the computer was booted.

As an alternative, I might suggest using Process Explorer. (Boy, it seems that I've been pushing PE a lot lately. Oh well. It's a great tool.) One can get a pretty good figure on the system uptime by examining the start time of the Session Manager process - smss.exe. Smss.exe is the first user-mode process created when the system boots. It is created by Ntoskrnl.exe and is a purely native application - it doesn't use Windows APIs. Instead, it uses what is known as the Windows Native API. An overview of the Native API can be found on the Sysinternals site at Inside the Native API. Gary Nebbett also wrote the book on the Native API - Windows NT/2000 Native API Reference.