Todd's Blog : General .Net Framework

.Net Framework Version Overview

Toddca — Wed, 08 Aug 2007 14:03:57 GMT

I am frequently asked about the various .Net framework versions floating around. As the .Net framework continues to go through its various revs the waters will only become muddier. Here is a quick overview of each version we have to date…

.Net 1.0 – This was the initial release of the framework which as of today only .Net 1.0 SP3 is currently supported by PSS. This only shipped as x86.

.Net 1.1 – This is a side-by-side release of the framework in which no dependencies on 1.0 exist. Hotfixes and Service packs for this version do not affect other framework versions. This only shipped as x86 and the latest Service Pack is SP1. This version also shipped inside the OS on Windows 2003 RTM but only in the x86 SKU. For x64 and IA64 versions of Windows 2003 there is no .Net framework installed by default. The x86 SP1 for Windows 2003 updates the 1.1 framework however it is SP1+ in that it does not have the same binaries as let's say a Windows 2000 machine with .Net 1.1 SP1 installed.

.Net 2.0 – This is a side-by-side release just as .Net 1.1. This version ships as x86, x64, and IA64. Windows 2003 R2 ships this version but does not install it by default. Using add/remove programs on any SKU will allow for installation. There currently is no service pack for this version. The x86 and x64 redist packages can each be installed side-by-side on a single x64 system.

.Net 3.0 – This is the first add-on framework. It adds functionality in the form of WPF, WCF, and WF, plus upgrades the 2.0 binaries by adding a few necessary fixes to make the new components function properly. This version shipped with all SKUs of Vista and has a redistributable package as well. The 3.0 redist package will install the 2.0 framework should it not be present or will upgrade an existing 2.0 installation. The x86 and x64 redist packages can each be installed side-by-side on a single x64 system. Currently there is no Service pack available.

.Net 3.5 – This is another side-by-side for 2.0 and 3.0 which adds functionality and updates the binaries of the previous two frameworks. This version has not been released and not much about it is public at this point but you can assume an x86, x64 and an IA64 version will continue to be available. You can probably also assume this will debut with Windows 2008.

Download your Hotfixes!

Toddca — Fri, 27 Jul 2007 15:34:00 GMT

Up to this point Microsoft has always required customers to make a phone call into Microsoft Product Support to receive a hotfix. Today we have made available a web application that allows customers to fill out a simple web form and receive the hotfix by email.

Here is how it works: The form on the site has field entries for the following information:

Country/Region (Pulldown menu)

KB article number (Text entry)

Platform (Pulldown menu)

Product Language (Pulldown menu)

E-mail address (Text entry)

You enter the data listed above and select the "Submit" button . You are then taken to a submission confirmation webpage. This webpage lets you know that you should receive a response from a Microsoft Professional within 8 business hours. The e-mail response that you receive looks like the automated hotfix e-mail that you may have seen should you have ever used the previous call in method.

Happy Hotfixin'.

Todd

Bytes In All Heaps > Private Bytes?

Toddca — Mon, 18 Sep 2006 14:21:00 GMT

The other day I had a friend of mine approach me about a possible bug he had found in the CLR memory perfomance counters. He pointed me to a performance log where his customer had captured a log that showed that the Bytes in All Heaps exceeded that of Private Bytes. Since he knew that Bytes in All Heaps represented the memory in the managed heap and the managed heap is part of Private Bytes how could this be possible? Well the answer is quite simple, its not, and what he was looking at was not a performance bug either but a side effect of how the GC performance counters operatate. The GC only updates it performance counters after a garbage collection as that is the time at which the values that feed into the counters are the most stable and available to publish to the performance block. It just so happens in this performance log that all GC activity had stopped for a while just before the end of the log (probably at the end of a test run) so the counters where not being updated. The private bytes counter will continue to be updated as it is managed by the OS.

Event Handlers Gone Wild

Toddca — Wed, 06 Sep 2006 00:10:00 GMT

Today I ran across an issue that my good buddy Tess hit with one of her customers a while back.

The application in question here is an ASP.NET web application that is exhibiting fairly high memory usage after almost a day of usage (approx 400-500 MB). Just as in Tess's case the number of event handlers was really high as you can see from this snip of the !dumpheap -stat command:

MD,Count,Size,Name
=====================================
0x024cd82c 876,697 24,547,516 System.ResolveEventHandler
0x019e4300 156,448 29,216,964 System.String
0x000cf740 238 66,842,468 Free
Total 1,464,956 objects, Total size: 182,475,044

Note that when working managed high memory issues I always start with !dumpheap -stat to get the landscape.

The customer stated that they were registering for the AppDomain's AssemblyResolve event in the global.asax and provided the code that showed what they were doing. Now the code below is incorrect and we will get back to that in a bit however even being wrong it still could not account for over 867,000 event handlers being added to AppDomain's event.

public HttpApplication() : base() {
AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(MyAssemblyResolver.ResolveAssembly);
}

So given the time the application had been up (approx 21hrs) there must be some common code that is getting called to register for these events elsewhere. I found the code in a class they use to derive all of their WebForm classes from; a custom BasePage class. Of course we are having them remove that code and that should get them back in much better shape.

Now how do we fix the global.asax code. Well the problem here is that a new HttpApplication is created each time one is needed by a web application and this means you could have more than one handler registered. Now if you have a really low volume site you will only ever see one of these in most cases, however as your traffic gets heavier additional HttpApplications will be spun up to handle the concurrent requests. Think of the number of HttpApplication objects as your high watermark for the number of concurrent requests your site has seen.

So the fix is to only register for this event handler once and doing this through a static constructor of the HttpApplication would probably be the best approach (though not the only). Since the CLR ensures that static constructors are only called once per AppDomain this will ensure we do not register for the handler multiple times.

static HttpApplication() {
AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(MyAssemblyResolver.ResolveAssembly);
}

The Wait Class

Toddca — Wed, 04 Jan 2006 17:31:00 GMT

Back when I did most of my coding with C++ I really liked the simplicity and compactness of using class constructors and destructors to do simple tasks such as setting a wait or busy cursor. For example, consider the code in Figure 1. It is a compact and simple API that is very easy to use and hard to use incorrectly.

void SomeClass::SomeMethod()
{
//at this point the constructor would run and set our
//cursor to busy.
CWaitCursor cur;

//do some work here

}//at this point the destructor would run setting our
//cursor back to its original state.

Figure 1

Today however I use C# as my primary development language and wanted to keep with what I knew worked in the C++ world so well. Since the CLR does not run the destructors (or finalizers) on its objects at predictable times there needed to be some modification to how I would implement and use the C# version of CWaitCursor (Figure 2).

internal class Wait : IDisposable
{
Cursor _savedCursor;
Form _form;

public Wait(Form form)
{
    if(form == null)
      throw new ArgumentException("form");

    _form = form;
    _savedCursor = _form.Cursor;
    _form.Cursor = Cursors.WaitCursor;
}

public void Dispose()
{
    _form.Cursor = _savedCursor;

}
}

Figure 2

Now to use my Wait class all I need to do is instantiate a new instance within one of my Forms, pass a reference to that form and use the "using" construct offered by the C# language.

public void SomeMethodOfAForm()
{
using(new Wait(this))
{
//do some work here

}
}

Figure 3

Ok at this point I should say I don't want to get into any debate with anyone over which language is better, which method is more preferred, etc... I will also point out before I am sure someone else will that this cannot be used with ASP.NET, ok you got me!

Correction: Rico was kind enough to point out that my Wait class was not finalizable so I did not need to SuppressFinalize on it.

Normal Users On Terminal Server Fail To Run .Net Framework Applications

Toddca — Wed, 08 Jun 2005 16:22:00 GMT

Yesterday I spent a couple of hours running through a live debug via Office Live Meeting (OLM) to narrow down a customer’s issue. The customer was attempting to run a .Net control from his web pages. These work fine if the user is an admin or a normal user logged in directly to a Windows 2000 SP4 machine however if the account is a normal user and if they are using Remote Desktop (Terminal Server Client) to connect to the server the control will not load. Other CLR/.Net applications fail to load as well.

The problem is that we get an Access Denied error when we call into CreateFileMapping when creating a block of memory for IPC. The call returns a NULL with a GetLastError of 5. This failure bubbles back up and causes the CLR to fail to load. A global is set so that the operation is not retired until the browser is restarted.

This problem occurs if all the following are true:
1. You log on to the Terminal server as a limited user (a user without administrator rights).

2. The Terminal server is running Microsoft Windows 2000 Service Pack 4 (SP4) and has the .NET Framework 1.0 installed with or without any Framework SP (in my case we had SP3 installed).

3. The .NET Framework 1.1 or later has not been installed on the machine.

To work around this problem without installing the 1.1 framework:

1. On the Windows 2000 SP4-based Terminal server, locate the following registry subkey:

            HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Kernel

2. Add the following registry values:
                        Value name: "ObUnsecureGlobalNames"
                        Value type: "REG_MULTI_SZ"
                        Value data: "Cor_Private_IPCBlock"
                        Value data: "netfxcustomerfcounters.1.0"
                        Value data: "SharedPerfIPCBlock"

3. Restart the server.

Issues similar to this one are documented in the following KBs:

823485 Errors occur when you use a .NET Framework 1.0-based program on a...

823502 Cannot Create a New Visual Studio .NET Project on a Windows 2000

The 1.1 Framework creates these registry entries when it is installed so installing the 1.1 or 2.0 framework as the KBs suggests will resolve the issue however may create a new one. The CLR shim mscoree.dll will attempt to always load the latest version of the CLR installed on the machine when loading an assembly through a COM interop such as what we are doing here when IE is loading our control. If the control is not compatible with the latest version it may fail to load or work properly. For more information on how to configure the loading of a specific version of the CLR go here.

The registry key “ObUnsecureGlobalNames” holds a list of object names. If an object is listed in the key, calls to ObpIsUnsecureName against that object will return TRUE. This is a way around for normal users who do not have the SeCreateGlobalPrivilege right which is typically required to create global objects. If the name is unsecured (i.e. listed in this registry value), access to and the creation of such objects in terminal server sessions is permitted.