Vlad Hrybok's Tech Notes - Software Testing

Guest Operating Systems Supported by Microsoft Hyper-V

Vlad Hrybok — Sat, 24 Oct 2009 21:32:20 GMT

http://support.microsoft.com/kb/954958

BTW, Windows 7 and Server 2008 R2 have Hyper-V HAL drivers in them, so when those two are installed as guest OSes, they take advantage of hardware virtualization even during installation, which makes the installation process go much faster compared to other guest OSes, and at the end of the installation one does not need to install Hyper-V integration services.

Why Managed Windows Services Hog Memory and Eventually Crash

Vlad Hrybok — Thu, 30 Oct 2008 02:52:59 GMT

It's very easy to write a windows service using C# or VB.NET. Easy to write, easy to install, but for a price.

It's an often overlooked fact, but in .NET runtime, Garbage Collector does not merge together freed memory chunks, if they are larger than 85K. What does it mean? It means that if your managed windows service allocates and frees buffers larger than 85K on a continuous basis, your service will crash because it will eventually run of memory due to Large Object Heap (LOH) fragmentation. Again, it will only happen if your managed windows service allocates objects of 84,000+ (give or take) byte, but IT WILL HAPPEN!

There are workarounds, somewhat expensive, like wrapping your service logic in COM+ server-activated process, which can be set up to recycle - just like IIS AppPools are recycled. Or one could create a proprietary memory manager with a pool of large buffers, making of which, of course, would be kind of ironic since the whole point of having garbage-collected memory manager was to eliminate hassles of memory management.

Anyway, the purpose of this post is to raise awareness among fellow windows service developers. If your service is high-throughput, high memory usage, it will go down in flames even if your code is perfect. The choices are: a) ensure all your memory allocations do not take more than 84K, b) implement your own memory manager, or c) implement worker process recycling.

Good luck to all of us.

Download WebService Studio 2.0

Vlad Hrybok — Mon, 19 May 2008 14:32:03 GMT

WebService Studio 2.0 (a.k.a. Web Service Studio) is a quick & dirty web service client tool that can import your web service's WSDL and allow you to call web service's methods without having to create your own test client.

WebService Studio used to be hosted on Microsoft's GotDotNet web site, but ever since GotDotNet was replaced by Codeplex, Web Service Studio was nowhere to be found. Fortunately, some kind stranger made WSS available for download at his blog: http://mattharrah.com/blog/web-tools/net-web-service-studio-20/.

Update: BTW, if you are planning to use WebService Studio to test WCF web services, you will need to configure your web service to use basicHttpBinding instead of wsHttpBinding.

How Windows Performance Counters of "Average" Types Linked to Their Bases

Vlad Hrybok — Thu, 20 Mar 2008 22:04:21 GMT

Some time ago I added performance counters to the application I was working on, and for some inexplicable reason all counters of "Average" type, like AverageCount64 or AverageTimer32, didn't work at all, always having 0 value. Then I had no time to find out why it was not working, but today I did. As you may know, "Average" counters are made of two distinct counters: the base counter and the average counter itself. The mystery was that by looking at all the samples returned by Google, it was unclear how the Base and the Average itself are linked together. It looked like you create the Base and the Average, add them to the collection and somehow magically Windows figures they need to be linked together when averages are calculated. After some research it looks like the two are linked by counter name! It appears that base's name should be the name of real counter, plus word " base". For example, when you define your counter category that has average performance counter, you do something like this:

counters.Add(new CounterCreationData("whatever", "whatever desc", PerformanceCounterType.AverageCount64));
counters.Add(new CounterCreationData("whatever base", "whatever base desc", PerformanceCounterType.AverageBase));

To my surprise, changing the "whatever base" value of the counter name in both CounterCreationData and PerformanceCounter to something like "whatever base1" breaks the perf counter! It looks like there is a naming convention requiring that AverageBase proformance counter has the CounterName property value on both CounterCreationData and PerformanceCounter to be counter name plus " base", but I never saw this mentioned anywhere - neither by MSDN, nor by Codeproject articles. So, since average perf counters always come in pairs, linked by name, these helpers should make creating average perf counters simpler (uinsg C#/.NET):

private static void AddAverageCounterDefinition(CounterCreationDataCollection counters,

string counterName, string counterDescription, PerformanceCounterType averageType)

{

counters.Add(new CounterCreationData(counterName, counterDescription, averageType));

counters.Add(new CounterCreationData(counterName + " base", string.Empty, PerformanceCounterType.AverageBase));

}

public class AveragePerfCounter

{

private PerformanceCounter averageCounter;

private PerformanceCounter averageCounterBase;

public AveragePerfCounter(string categoryName, string counterName)

{

this.averageCounter = new PerformanceCounter(categoryName, counterName, false);

this.averageCounterBase = new PerformanceCounter(categoryName, counterName + " base", false);

}

public void IncrementBy(long val)

{

this.averageCounter.IncrementBy(val);

this.averageCounterBase.Increment();

}

After this, when creating performance counter definition, you could use following code instead of the one shown by the very first snippet:
AddAverageCounterDefinition(counters, "whatever", "whatever desc", PerformanceCounterType.AverageCount64);
It will add " base" to the name of the sidekick automatically.

And to create corresponding performance counter, you now can do this:
AveragePerfCounter avgCount = new AveragePerfCounter("MyCategory", "whatever");
avgCount.IncrementBy(new Random().Next(100));

Use Remote Desktop to access Windows virtual machines running under VmWare Server or MS Virtual Server

Vlad Hrybok — Sat, 03 Feb 2007 17:19:30 GMT

If it takes too long to redraw the screen when you access your remote virtual machine using VmWare Server Console or Microsoft Virtual Server admin page, consider terminaling into your virtual machines using Remote Desktop or Terminal Server client. UI works as fast as with any "real" remote PC. Entry-level Windows XP Home and Vista Home don't support Remote Desktop, but all Pro, Business, Media Center Edition and other flavors of Windows Vista, XP and 2003 work just fine. One of my co-workers told me Remote Desktop can be used for VmWare Workstation access, but I also tested VmWare Server and Microsoft Virtual Server R2, and those two also do it.

To enable Remote Desktop access a few things usually need to be done:

1. Enable RD access:

2. Ensure your user account is a member of the Administrators group.
3. The password on your user account is not blank.

The only issue I had with this setup was sometimes I couldn't ping the virtual machine due to networking issue. But when that happens all attempts to access that virtual machine over the LAN fail, including NetBIOS file shares, web access - anything.

Your Intel EMT64 CPU has to have VT support to run 64-bit guest Windows OSes on VmWare Server

Vlad Hrybok — Fri, 19 Jan 2007 03:08:20 GMT

I need to test my software on a variety of 64-bit Windows versions. I hoped I would be able to use Microsoft Virtual Server, which I've been successfully using for a while for 32-bit tests (including German, Russian and Korean flavors of Windows - quite a feat for a Ukrainian with English as a second language), but to no avail - at this point even latest MS Virtual Server is unable to host 64-bit guest operating systems. So despite enjoying being lazy, I was forced to check out free VmWare Server. I hoped to run it on my main Vista x64 dev box, but VmWare Server did not install correctly on Vista x64. That was quite a setback for my product delivery schedule, because I realized I needed another box with 64-bit Windows 2003 Server on it to be sure I could run VmWare Server. I dug through my closet with PC parts and after combining what I had with $200 worth of parts bought from NewEgg.com I had a modest 64-bit box with Pentium D 805 and 1GB of DDR memory. VmWare has installed without a problem, but when I attempted to install Windows XP x64 VmWare Server told me that my Pentium D CPU is no good because when it comes to Intel CPUs, 64 bit guest OSes can run only on EMT64 units with Virtualization Technology (VT) support! Fortunately, my dev desktop had Core 2 Duo E6300, which does have VT support, and both Pentium D and Core 2 Duo use the same LGA 775 package, so I was able to simply swap CPUs and ta-da! - after that VmWare finally started cooperating and is installing XP x64 guest OS as I'm typing this article.

Conclusion: If you want to run 64-bit guest OS in VmWare using Intel CPU you will need a box with a processor supporting Virtualization Technology, and run Windows 2003 x64 as a host OS.

"Service Unavailable" error when accessing VmWare Server web admin running on Windows 2003 Server R2 x64

Vlad Hrybok — Thu, 18 Jan 2007 05:25:19 GMT

After installing VmWare Server on 64-bit Windows 2003 Server R2, I was unable to access VmWare Server's web admin page due to Service Unavailable error. VmWare support forum suggests to remove .NET Framework 2.0, which seems to help some people, but I fixed the problem by repairing .NET Framework 2.0 installation after VmWare server was installed. To do that go to Control Panel -> Add/Remove Programs, select .NET Framework and hit Change/Remove button. In the dialog select repair and let it run. After that both Default Web site and VmWare web site were running fine.

Microsoft Virtual Server R2 SP1 on Vista x64 and Intel Core 2 Duo CPU

Vlad Hrybok — Sun, 17 Dec 2006 19:29:12 GMT

Microsoft Virtual Server R2 SP Beta works really well on Vista x64 and Intel Core 2 Duo E6300 CPU, which has Virtualization support. Installer was not completely hands-off - I had to add CGI module to IIS7 manually - otherwise VSWebApp.exe was treated as downloadable file and not as CGI module. MS needs to update VS installer to automate this step.

Please note that although MS Virtual Server R2 Beta can run on Vista x64, it can't host 64-bit OSes. To host 64 bit OSes you would need free VmWare Server installed on x64 Windows 2003 Server, and either AMD 64 bit CPU or Intel EMT64 CPU with Virtualization Technology (VT) support (like Core 2 Duo E6300 or E6400 CPUs).