This is one of those deep nerdy windows internals posts that will interest some and make other say "wow,  Tom needs to spend more time away from his computer".  There is actually a good reason why I've dug into this topic and it stems from my recent hardware allocation in my new job.  When I started I received a new Lenovo laptop with 4 GB of memory and my base image came with Vista 32 bit.  I didn't think too much of it and loaded everything up.  This was about 6 months ago so there was no Vista SP 1 at the time. 

To my dismay when I opened my computer properties I saw that I only had 3070 MB of available physical memory.  So somehow I lost an entire gig of RAM.  I spoke with some of my other colleagues that were also new hires and they didn't have the same issue.  Many of them had HP or Dell notebooks and they had more like 3.5 GB of available physical memory on their machines.

It was right around this time that I got my first deep internals class for my new job.  In this class we learned all of the tips and tricks for doing advanced perfmon analysis of memory leaks, disk performance issues, CPU bottlenecks, the list goes on and on.  Well the instructor was just incredible so when there was a break in the class I asked him about this issue.  He very quickly explained that the reason you see different amounts of available ram was because of the chipset and reserved space for device drivers (video cards typically the biggest hogs).

Ok,  no big deal then right.  Lesson learned,  when you look to purchase a laptop that can support up to 4 GB of physical memory make sure you find out how much it will make available to windows.  Then,  Vista SP1 came out and I couldn't help but notice when I went to the computer properties the window now said I had 4 GB of ram available.  Well isn't that interesting,  someone must have lied to me!!!!  Actually it turns out that with SP1 we decided to show the installed RAM instead of the available RAM.  This is very confusing as it's never been that way for any previous OS version.  If you want to learn some more about it you can take a look at this kb article http://support.microsoft.com/kb/946003/. 

Now my story here is one of confusion and ignorance.  If you're the type that wants to really understand this stuff then you have to go the best windows internals guy on the planet.  Of course I'm talking about Mark Russinovich,  he wrote a long blog post just this week (which is what reminded me I wanted to blog about this) that gives a complete explanation of this issue along with some other really cool stuff about RAM limits on other OS versions.  He also shows a screenshot from the largest test server in the world used to define the limits for memory in 64 bit windows (currently 2 TB because there was nothing any higher available that we could test with).  This is a must read http://blogs.technet.com/markrussinovich/archive/2008/07/21/3092070.aspx.  If you just want the technical detail behind the 4GB issue I talked about above then scroll down to the "32-bit Client Effective Memory Limits" section.

So the main lessons here are:

     1) If you are still planning to run 32-bit windows clients and you plan to install more than 3 GB of RAM then not all hardware is created equal.  Make sure you ask how much physical RAM is made available to windows.  This becomes even more important when you start doing a lot of Virtual Lab work as I often do.  It sure would be nice to get that third Win 2K3 server running with a full GB of RAM.  Why didn't I install the 64 bit version of Vista Ultimate again?

     2) The 64-bit client version of windows is really the only way to ensure you can start to have enough RAM for doing a lot of virtualization work.  It's also the only way to get in and see how many gaps your hardware has left in the device driver ranges (see Mark's review of this).  64-bit is the future ... embrace it ... love it ... live it.

There are two reasons why I went ahead and deleted my other blogs today.  The first is that I finally came to grips with the reality that managing three blogs is not very realistic.  That was probably evident by the fact that each of those blogs had about 2 postings.  So I'll be adding some new blog posts in my good old SOA focused blog that have maybe some out of bounds topics (like support, debuggin, and SQL BI).

The second reason for consolidating my other blogs is that I'm finding that the technology gods, in their infinite wisdom, have carved out a path for me in my new role at Microsoft that leads to SOA.  Three areas I've been spending a lot of time on the last two months are WCF, BizTalk and the Managed Services Engine (codeplex.com/servicesengine).  You may have noticed this in the form of some more technical postings on WCF and BizTalk recently.  Well that's only the beginning.  I have quite a few more active support cases where I'm learning really interesting stuff and I'm about to head out to Seattle for 10 days of training.  Half of that training will be on all of our SOA related bits from the SOA Solutions team.  Needless to say I'm really stoked.

Expect to see a lot of posts coming from me in the near future about all this stuff I'm working on.  I know I've said this before but I'm now focused and very excited because of the technology area I'm beginning to venture into.  Mr. SOAPitStop is back baby!!!!

Before I forget to do this I wanted to post about this issue because it cost me a 1/2 day of debugging and I hope to save you this agony.  It actually turns out there's a nasty little issue when you use Virtual Server 2005 differencing disks to quickly stand up lab enviorments.  In my new role with Microsoft support I'm constantly setting up 1, 2, 3, and sometimes 4 node lab environments so differencing disks are pretty much a must.  Of course if you want to do this and still need the ability to join these servers to a test domain, then you have to make sure you rename / resid them.  That's where I've always relied on newsid from the sysinternals tools. 

 I've always wondered if this was a hack (versus a full sysprep) and I wondered when it would jump up and bite me.  I noticed in IIS that the anonymous user account does not get recreated to use the new computer name but that's never impacted me (I sort of figured a local account really isn't going to make much of a diff).  Well,  I have now finally found an issue that is ugly.  It turns out that if you are going to build an app server / db server both from the same base OS image you are going to have some issues with MSDTC.  I ran into this as I started to run through the BizTalk configuration tools.  I kept getting the following error:

 2008-07-08 17:44:58:0896 [ERR] WMI Failed in pAdmInst->Create() in CWMIInstProv::PutInstance(). HR=c0c025b3
2008-07-08 17:44:58:0906 [ERR] WMI WMI error description is generated: Exception of type 'System.EnterpriseServices.TransactionProxyException' was thrown.
2008-07-08 17:44:58:0936 [INFO] WMI CWMIInstProv::PutInstance() finished. HR=c0c025b3
[5:44:58 PM Error BtsCfg] d:\depot2300\mercury\private\mozart\source\setup\btscfg\btswmi.cpp(358): FAILED hr = c0c025b3

[5:44:58 PM Error BtsCfg] Exception of type 'System.EnterpriseServices.TransactionProxyException' was thrown.

At least this error helped me narrow down the root cause of the problem which is obviously System.EnterpriseServices.  So I started looking at all my settings for MSDTC and nothing seemed out of the norm.  All the right security settings and network dtc access settings were there.  So it was time to do a quick search with live.com (that's right ... I said live.com ... google is so 5 years ago :)

It turns out the problem is with the underlying CID settings for MSDTC.  It looks like newsid doesn't go in and take care of these.  Fortunately I wasn't the first one to come across this because I don't know if I would have come up with these steps.  A big bravo goes out to Wade Wegner who wrote a great overview of the problem and the steps to fix it.  You can read the full description and steps to identify wether or not this is your issue here:  http://blog.wadewegner.com/2007/08/13/quotWarningTheCIDValuesForBothTestMachinesAreTheSamequot.aspx.

If you just want the solution you can follow these quick steps on both machines. (taken from Wade's blog).

Use Add Windows Components, and remove Network DTC.
1. Go to the command line and run: MSDTC -uninstall
2. Go to the registry and delete the MSDTC keys in HKLM/Software/Microsoft/Software/MSDTC, HKLM/System/CurrentControlSet/Services/MSDTC, and HKEY_CLASSES_ROOT\CID. *
3. Reboot
4. Go to the command line and run: MSDTC -install
5. Use Add Windows Components, and add Network DTC.
6. Go to the command line and run: net start msdtc **

* for me the CID settings were deleted when I did the -uninstall so you shouldn't need to remvoe the last ones.  Also,  this does mean you should delete the key at the top level and purge all the subkeys,  that freaked me out a little at first but of course we're just talking about a test lab here so I figured why not try it.  It worked like a champ.

** This step wasn't required for me as the service was already running following me adding the network DTC access from the windows components installer.