Process Explorer and Different Versions of the .NET Framework

Previously, I had discussed an enhancement to Process Explorer that would allow it to identify / indicate what version of the .NET Framework a process had loaded. I have submitted this as a feature request on Sysinternals Forums (here and here).

Process Explorer and Vista's Protected Processes

FWIW, on Sysinternals Forums I have submitted a feature request (here and here) for Process Explorer to be able to identify "Protected Processes" in Vista.

Not much discussion on it yet, though...

Idea for Process Explorer Enhancement

In a recent blog entry's exploration, I was determining which ".NET" processes were using what versions of the .NET Framework. The method that I was using for this was to find the ".NET processes" in Process Explorer (highlighted in Yellow by default) and either note the version of MSCOREE.DLL, or check the path of DLLs that are loaded into the process' address space - if %WINDIR%\Assembly and 2.0.0.0 or 2.0.50727 show up, the process is using the .NET Framework 2.0. Substitute appropriate version numbers for other versions of the .NET Framework.

Then, because I'm lazy, I started thinking... what if Process Explorer could tell me this information without me having to dig a little bit for it? Process Explorer could highlight processes, using a configurable color, to indicate the version of the .NET Framework the process is using. E.g., processes with DLLs from the .NET Framework 1.1 would be highlighted in yellow, processes with DLLs from the .NET Framework 2.0 would be highlighted in blue, etc. By default, the colors could all be set to yellow, but the user could specify their own color for each version of the .NET Framework.

Another consideration might be to add this information in a column that can be displayed in the upper pane of Process Explorer.

Force an App to Use a Specific Version of the .NET Framework

I was whipping through the list of processes in Process Explorer that were ".NET" processes (processes that had some version of MSCOREE.DLL loaded into their address space). I'm still under ten, out of 75 processes total. I was curious as to what versions of the .NET Framework were being used as I had 1.0, 1.1 SP1, and 2.0 installed.

As How to: Use an Application Configuration File to Target a .NET Framework Version states, by default an application will run on the version of the .NET Framework that the application was built on, if it is present on the computer.

Most ".NET" processes were using the .NET Framework 2.0, which is what I expected. But two were using version 1.1. Since many / most apps should work fine with any "future" version of the .NET Framework (it's supposed to be backwards compatible) I thought I would try running them against the .NET Framework 2.0. The apps in question are SharpReader (0.9.7.0) and Red Gate Software's FREE SQL Prompt 2.0.

To get the apps to run against the .NET Framework 2.0, I simply added the supportedRuntime element to the startup section in the app's app.config file (progname.exe.config). At its most basic (for this purpose) the config file would look something like:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <startup>
        <supportedRuntime version="v2.0.50727" />
    </startup>
</configuration>

After making or changing the app config files for SharpReader and SQL Prompt, I ran the applications. Without extensive testing, the apps appear to be running and functioning just fine while using the .NET Framework 2.0.

Yet Another Potential Resolution for Error 0x8ddd0009 from Windows Update / Microsoft Update

[See the sidebar at the right on the entry page for more links to information about error 0x8ddd0009 and Microsoft Update / Windows Update.]

Microsoft released Knowledge Base article 916089, FIX: The computer may stop responding for 40 or more seconds when you run a scan for updates or when you try to apply an update on Windows Server 2003, on Windows XP, or on Windows 2000. As many people report an unresponsive system and high CPU utilization prior to receiving the 0x8ddd0009 error from Microsoft Update / Windows Update, it stands to reason that applying the hotfix presented in the article may be of help to some people.

Unfortunately, the hotfix requires one to contact Product Support Services.

The culprit appears to be Windows Installer. Windows Installer 3.1 v2 is a prerequisite, and the only file included in the hotfix is MSI.DLL (dated October 2006).

The KB article states:

This update decreases the duration of a scan that uses the Windows Update Agent. However, a scan is still a CPU-intensive operation. The Svchost.exe process contains the Automatic Updates service. When you perform a scan, the Svchost.exe process can cause CPU utilization to reach 100 percent for a prolonged time. For example, Microsoft Office updates use Windows Installer. When Microsoft Office updates are detected, these updates can contribute to 100 percent CPU utilization for a prolonged time.

If you try this update and it helps, please post a comment about your experience!

How do you apologize to an audience that's not likely to see the apology?

Sigh.

To all that are not finding what they're looking for because they were directed to what is now a non-existent page on the TechRepublic site, I apologize. I understand that you may not find this apology, but what else can I do?

TechRepublic has gone and decided to do away with Member Blogs. I received the following email on 2006-10-03:

TechRepublic Blogger:

As many of you know, we are preparing to launch a new version TechRepublic. This revamp brings a fresh new look-and-feel to the site as well as improvements to features and functionality.

http://techrepublic.com.com/html/tr/preview/updated_TechRepublic.html

The process of revamping the site forced us to make some tough decisions about which features we would support going forward. Unfortunately, our member blogging feature didn't make the cut. So, with the launch of the revamp, we will be changing our approach to blogging on TechRepublic. Instead of giving every member the option to blog individually, we will be building a dozen or so topical blogs that have multiple contributors.

Starting next week, member blogs will no longer be available on TechRepublic. THIS MEANS THAT YOUR BLOG POSTS WILL NO LONGER APPEAR ON THE SITE AFTER THE LAUNCH. We apologize for any inconvenience that this causes; however, we feel that our new approach to blogging will better serve all of the members of TechRepublic.

Please feel free to contact me with any questions or concerns you may have.

Sincerely,

---------------------------------------------------------------------------------------
Shawn Morton
Site Manager - TechRepublic, CNET Networks

So, they're basically pulling my TR blog. That's fine, I guess - the blogging software sucked (it wouldn't work well with IE, it couldn't / refused to pull from the atom feed here, etc). But I wish they could account for the fact that they're effectively breaking links. Redirect people somewhere useful (perhaps this blog) when they go to my old TR blog. Or let me put up a message. Something. Now, you (usually) just get barfed out to the root topical blog collection they've started. Some of the old blog content is still accessible but I suspect that as they continue on with their site mods that stuff will be pulled.

So again, if you went to TR looking for something and couldn't find it, I'm sorry.

On a brighter note, at least I didn't have all of my eggs in one basket...

Using the Command Prompt with Network Drives

I've been using the command prompt with mapped network drives lately. I usually set up my PROMPT so that the UNC path that the drive letter represents displays, along with the normal prompt info. There are a couple of ways to do this. It can be accomplished on an ad hoc basis by simply entering set PROMPT=$M$P$G at the command prompt. The prompt will change to something like \\server\share\foldername X:\> when one is on a mapped drive. One could further simplify this by putting it into a batch file and running it when necessary.

Of course, setting the prompt to this doesn't hurt anything, so why not make it a bit more permanent? One can use the "System Properties" to get to the "Environment Variables" on the "Advanced" tab (in XP, at least). From there, set either a USER (applies to the user currently logged on) or SYSTEM (applies to all users) variable named "PROMPT" to $M$P$G.

I also usually prepend $+ to my PROMPT. This adds one '+' character to the front of the prompt for each level into the PUSHD stack that one is. PUSHD / POPD are commands that can be used to push / pop directories to / from a stack of directories that the command prompt keeps for you. If you're 10 folder levels deep and need to bounce to \TEMP, PUSHD to \temp (PUSHD C:\TEMP) and do your work. When you're done, POPD and you'll be back to the folder that's 10 levels deep. With $+ in the PROMPT ($+$M$P$G), the prompt will look like ++\\server\share\foldername X:\> when the "PUSHD" command has been executed twice without POPDing.

Attacking DCOM with Metasploit

EthicalHacker.net has a pretty cool video showing how to use Metasploit's Meterpreter to launch a DCOM attack.

Using COM in UMDF Drivers

On WHDC Microsoft has posted A COM QuickStart for UMDF Developers. The document goes over some high-level COM details as they apply to use in the user-mode driver framework.

The COM run time is not used. Rather, the core COM programming model is used to make programming the drivers easier. It is naturally expected that C++ will be used to write the UMDF drivers, though C can be used at the expense of simplicity / convenience. Of course, if past experience is any indication reference counting will likely be a sore spot...