Bug me

Hidden feature of VSIP: Sharing a machine

2007-05-04T02:58:00Z

Okay so this really isn't a debugger feature, but I thought it was handy anyway.

Yesterday a colleague and I were both logged onto the same machine, both using Visual Studio as two different users. Since I work at Microsoft, I naturally needed to change Visual Studio. So how to do that without having my co-worker log off (because he had the same dlls loaded I needed to change)?

Registry hives

VSIP (well actually Visual Studio) has this nifty idea where you can load devenv using a different root key in the registry. The intent here is that when you are developing a Visual Studio package you can build the package in one instance of Visual Studio and run in another. This means the package is not loaded in the same environment you are building in. Very handy when your package causes Visual Studio to crash. How would you debug it if you can't even start Visual Studio?

So most of the time (at least in my past) people use the Exp hive. If you look in your registry, you'll have a root install of HKLM\Software\Microsoft\VisualStudio\8.0. The Exp hive lives at HKLM\Software\Microsoft\VisualStudio\8.0Exp. If you install your package in just the Exp hive, you can run the Exp version and debug with the normal.

Package redirect

So how did I use this exp hive to my advantage?

Packages are loaded dynamically as devenv needs them (usually when a command or window from the package is called). The location for these packages is stored in the registry underneath the root location for Visual Studio (i.e. HKLM\Software\Microsoft\VisualStudio\8.0\Packages\{package guid}).

For example, the debugger package (which is what I wanted to change) is loaded from here:

Since my colleague was using the 9.0 hive, I could just change the package load location for my Exp hive and have my version of devenv load a different dll!

Something like so:

The next level of DLL Hell - SxS.

2007-04-09T23:34:00Z

Everybody seems to be having SxS problems. I know I have them all the time.

SxS (or side by side) was a solution Microsoft developed for people distributing the C runtime with their application.

I won't comment on whether or not this was the right solution to the problem, but I'll talk about what I do to resolve it.

Is it SxS?

Anytime an application doesn't load a dll or refuses to start for some reason, I suspect SxS. Usually you'll get something like:

The application has attempted to load the runtime library incorrectly. Contact support for more information

This application has failed to start because the application configuration is incorrect

At this point, I do one of the following to make sure it is a side by side issue:

Open the event log in (XP/Vista) and look at the Application or System list. There should be a SxS error in there somewhere
Open the offending dll or exe using depends.exe (usually installed with Visual Studio under Common7\Tools\Bin). It will tell you if there is a SxS issue.

Do I have that CRT installed?

So one reason you might be having sxs problems is you don't even have the appropriate run time dlls installed. Usually this isn't the case, but I say it here first just to make sure you check.

To check if you do:

Open the event from the event viewer that identifies what dll it is trying to load. Vista shows something like so:

Component identity found in manifest does not match the identity of the component requested. Reference is Microsoft.VC80.ATL blah blah blah

Go to your Windows\WinSxS directory and see if you have a directory with a name containing the reference. Vista could have multiple.

If you find a directory containing the name of the runtime, then some version of that runtime is installed. You probably need to redirect.

Redirecting - Fixing the problem

Obligatory warning: Mucking with system files can screw stuff up later on. Not that I've had problems after doing any of these fixes, but people say it's unsupported. I wouldn't recommend this as a "fix" but rather a workaround on your development machine.

Anyway, here's what I do depending upon the platform:

XP/2003 Server

Go to the event log. Find the error that names the dll you are having trouble with (there might be 3 or more errors for your one side by side load)

Go to the Windows\WinSxS\Policies\<goofy directory containing your CRT dll name>

Edit the .policy file with the largest number.

Change the binding redirect to be like so:

<bindingRedirect oldVersion="9.0.0.0-9.0.65535.65535" newVersion="9.0.xxxxxx.xxxxx"/>

The critical part here is that the the newVersion value matches the policy file's main number. Here's one on my machine:

name="policy.9.0.Microsoft.VC90.DebugCRT" version="9.0.20223.44800"

Make sure the number at the top of the file matches the newVersion you type in.

Vista

Go to the event log. Find the error that names the dll you are having trouble with (there might be 3 or more errors for your one side by side load)

Go to the Windows\WinSxS\Manifests

Find the newest manifest file with the name like so

x86_policy.8.0.microsoft.vc80.atl_1fc8b3b9a1e18e3b_8.0.50727.762_none_8e053e8c6967ba9d.manifest

The important parts being x86_policy and microsoft.vc80.atl - this name matches the runtime you are trying to redirect. The rest of the name doesn't really matter, although it should be the newest file and probably the highest version x86_policy file in that directory for your runtime.

My friend John discusses another alternative (at least on Vista) to find the appropriate file: sxstrace

Edit this file and change the binding redirect to be like so:

<bindingRedirect oldVersion="8.0.0.0-8.0.65535.65535" newVersion="8.0.xxxxxx.xxxxx"/>

The critical part here is that the the newVersion value matches the policy file's main number. Here's one on my machine:

name="policy.8.0.Microsoft.VC80.ATL" version="8.0.50727.44800"

Make sure the number at the top of the file matches the newVersion you type in.

Here's another caveat for vista = saving the file. You probably aren't the owner of this file. You need to remove whoever is the owner, and make yourself owner of this file before you can save it. I'll leave that step up to the user for brevity's sake.

After changing the appropriate policy file, your app should start to work. If it doesn't, hey you might have a dependency on another part of the CRT. Check the event log again :)

Update: How to tell when this isn't going to work

So I finally ran into a case when this workaround failed. When the CRT is actually different and your application is using the wrong CRT! Duh.

You'll get something like:

---------------------------
devenv.exe - Entry Point Not Found
---------------------------
The procedure entry point ?replace@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV12@V?$_String_const_iterator@DU?$char_traits@D@std@@V?$allocator@D@2@@2@0ABV12@@Z could not be located in the dynamic link library MSVCP80.dll.
---------------------------
OK
---------------------------

In this case you actually need to go through the correct channels - like trying to find this version of the CRT and installing it. Should be installed under:

Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86

You might also try a manifest for the appropriate dlls. Here's a blog entry about it.

PCs still suck

2007-04-09T21:29:00Z

Okay so I probably shouldn't be writing that as a title considering who I work for, but I had a rather frustrating weekend IT session. Since I work at Microsoft, all of my family and friends expect me to answer any obscure computer problem they might have. I wonder if doctors have this same problem?

I had 3 separate "support" calls this weekend:

My wife informed me that Win32 was not working on our laptop.
My in-laws told me that they couldn't see themselves when talking to us through video conferencing (and hence we couldn't see them either)
Our laptop was consistently blue-screening (separate issue from the first) during video conferencing.

All 3 of these problems would not be diagnosable by say my wife. In fact one of them was only fixable because of the specific knowledge I have from working here.

PC's still aren't ready or usable by home consumers. At least not without a lot of hand holding and support. How come we haven't fixed this yet? Why do PCs have to be so techie? Okay I know why, but the reasons/excuses seem shortsighted to me.

What if we had an OS where all drivers were controlled/written by the vendor. What if the whole OS allowed but a single app to run at a time? And what if you had to control it with say, a game controller, instead of a keyboard and a mouse?

I think for Christmas next year I'm buying everybody an X-box with live and a camera.

Now if only X-box live would come with a browser.

Hidden Breakpoint Feature: Stepping in just one thread

2007-03-30T11:00:00Z

So I was giving this demo the other day of some of our new concurrency features in the Orcas CTP and I found this "new" feature for breakpoints. At least it was new for me. Sorry I'm a noob :)

The code was something like so:

  451         private void ComputePrimes_ThreadProc(object obj)
  452         {
  453             ThreadParams threadParams = (ThreadParams)obj; <- Breakpoint here
  454 
  455             // Go through our range, determining if a number is a prime
  456             for (int number = threadParams.lower; number <= threadParams.upper; number++)
  457             {
  458                 if (IsAPrime(number))
  459                 {
  460                     // Then add to our list
  461                     _primes.Add(number); 
  462                 }
  463             }
  464 
  465         }
 
 

The problem I was trying to demonstrate, while stepping through some code, was a race condition occurring on a collection (one of our new features is supposed to help point this out). However, whenever I stepped, the other threads kept hitting the breakpoint, moving my ip indicator back to the breakpoint, and generally screwing stuff up.

Here's a screenshot of it in action (notice our new other thread indicators)

Yeah this is a pain. I want to just step in this first thread. I guess I could wait until the right thread gets to the breakpoint, then freeze everybody else. This doesn't seem to work though (mostly because of the internal state of the other threads)

But wait, there is a way to step in just this thread!

Here's how:

Right click on the breakpoint and select "Filter" from the list of options
When the filter dialog appears, type in a filter condition. I used ThreadName=<my thread name>
Click OK

Now when the breakpoint gets hit, only this thread will be in stepping mode. (Something else I learned, threads are in one of 3 states - stepping, running, or suspended)

So as you step, the IP indicator won't jump around.

Of course this then made me want more, but I'll leave that for another post.

Hello World

2007-03-30T02:46:00Z

Hi, my name is Rich Chiodo, and I work at Microsoft.

That sounds like an admission of guilt.

I suppose in some ways I do feel guilty working here. I work for the man now. No longer am I one of the free spirited plebes of the software world. I am now the property of Mr. Bill.

I've been here for 8 months as part of the Visual Studio Diagnostics team - specifically working in the Visual Studio debugger. I'm hoping that this blog will let me discuss some of the interesting things I've found (or am trying to do) with the debugger.