Hirlpoo West : Customer Learnings

Code Access Security and User Controls

ddysart — Tue, 08 Aug 2006 15:32:00 GMT

About a week ago I helped troubleshoot an issue where a customer wrote a WinForms User Control and she was trying to use it on a form she was developing. When she dragged it from the toolbox, she was getting the following error:

An exception occurred while trying to create an instance of Contoso.XP2.AuthorList. The exception was "Request for the permission of type System.Security.Permissions.FileIOPermission, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed".

No one else in her group experienced this issue. Right off the bat it smelled like a CAS (code access security) issue, the VS IDE was trying to create an instance of the control to use in the designer and was failing to get some permission (File IO in this case). In this case, a quick scan of the code for the user control showed that in the contructor it was reading some configuration information from the local HD.

This was a bit confusing to the developer, as she hadn't written any code yet, but the constructor was getting run. How could this be?

At design time, when a control is put onto the form in the designer, the Visual Studio process (DEVENV.EXE) will create an instance of your control to be able to display it on the design surface. In doing this, stuff like the constructor gets run.

The majority CAS issues we see stem from loading an assembly from a network share. By default, an assembly loaded from the network is not trusted as much, therefore things like File IO get restricted. But in this case, the developer was working with everything local. The project and the file being read were on the C: drive. Time to look under the covers.

I had her run the (recently aquired) SysInternals FileMon tool and filter on only the DEVENV.EXE process. After she sent me the trace, the following line looked suspicious (I added the line breaks):

7120 10:01:24 AM devenv.exe:784 QUERY INFORMATION \\chi-fs01\UserAppData\Devlogon\Application Data\Microsoft\VisualStudio\7.1\ProjectAssemblies\ipgr1g-i01\Contoso.XP2.DataAccess.Settings.dll SUCCESS FileFsDeviceInformation

What is with this "ProjectAssemblies" directory? And why was it on a network share. The "chi-fs01" naming convention of the server made it sound like a file server in their Chicago office (thanks IT!) and after talking with the developer some more, it turns out her home directory was redirected to a file share for roaming purposes. After a bit of digging, KB825007 looked like the exact same problem we were seeing, except a different error was occuring.

As I mentioned, Visual Studio will complile a temporary copy of the control so it can run it for display in the designer. It will compile this temorary copy to a folder in %APPDATA%\Microsoft\VisualStudio\7.1\ProjectAssemblies. When %APPDATA% is re-directed to a network share, the compiled assemby won't be trusted the same as one on the local hard drive and may fail. The workaround is to explicity trust this directory in the code access security policy:

Start the Microsoft .NET Framework 1.1 Configuration tool (located in Administrative Tools on the Control Panel). The .NET Configuration 1.1 window opens.
In the left pane of the .NET Configuration 1.1 window, expand Runtime Security Policy, and then expand Machine.
Expand Code Groups, and then expand All_Code.
Right-click LocalIntranet_Zone, and then click New. The Create Code Group dialog box appears.
Click to select the Create a new code group option.
In the Name box, type MyCodeGroup, and then click Next.
In the Choose the condition type for this code group box, click URL.
To fully trust all files that are located in the ProjectAssemblies folder, type the following text in the URL box:
file:////FolderPath\Microsoft\VisualStudio\7.1\ProjectAssemblies\*
Note: FolderPath is a placeholder for the path of the folder where the Application Data folder is redirected.
Click Next.
In the Use existing permission set box, click FullTrust, and then click Next.
Click Finish.

After completing these steps, she retried dragging the control from the tool box and it showed up on the form surface this time.

"Invalid Parameter" when receiving from a remote queue

ddysart — Fri, 17 Mar 2006 22:15:00 GMT

I'm backing up a colleague who is out on vacation this week and got an interesting issue from one of his customers. They'd implemented a simple Windows Service in C# (v1.1) to read messages from a remote MSMQ queue.

The issue they ran into is when the server the remote queue went down, they'd get "MSMQ Unavailble" errors, which is expected. Once the queue comes back online, they were getting "An invalid parameter passed to a function" After a bit of digging this looks to be a bug in the framework related to some caching of the connection to the queue. After the queue comes back up, the cached connection is no longer valid. Fortunately the workarounds (2) are fairly simple:

Disable the connection caching via:
System.Messaging.MessageQueue.EnableConnectionCache = False;

Clear the cache after catching the error and retry receiving on the queue:
System.Messaging.MessageQueue.ClearConnectionCache()

From what I could gather from reading the notes in the bug, it has been address, but I'm speculating since the workaround is fairly simple, no hotifx has been made yet. I'd expect it in a future release, I just have no idea which one.

Changes to authentication in XPSP2

ddysart — Thu, 17 Feb 2005 02:36:00 GMT

One of my customers ran into an interesting issue when upgrading their developer workstations to Windows XP SP2 - they stopped being able to debug ASP.NET applications running on the local IIS5.1 webserver. They went through the standard steps of ensuring permissions and appropriate security group membership, but it still failed. Turns out they have a less than standard configuration and ran into a new security check in Windows XP SP2. First their configuration.

They are running multiple websites on IIS5.1, which until this case I didn't know was possible. It is, as long as only one site is running at a time. Each site represents one of the potential sites their developers could be working on. Then each VS.NET is configured to point at a FQDN for the site. For instance, say the production web site was www.contoso.com, the dev project would be configured as www.contoso.dev. Then (and here is where things get interesting), www.contoso.dev is configured in their DNS servers to resolve to 127.0.0.1. Other projects have other DNS names that resolve to 127.0.0.2, 127.0.0.5, etc, etc. Since these are all in the loopback range, they all resolve to the local machine.

Forgetting about their reasoning for this for a moment, what was happening was authentication was failing on the website. We could see this from the IIS logs that looked something like this:

2005-02-25 16:20:20 127.0.0.21 - DEBUG /Default.aspx 401 398 Microsoft-Visual-Studio.NET/7.10.3077 -
2005-02-25 16:20:20 127.0.0.21 - DEBUG /Default.aspx 401 235 Microsoft-Visual-Studio.NET/7.10.3077 -

Browsing with IE to the DNS name with anonymous disable gave us the credential prompt, which would not take any valid credentials. The interesting thing was this - if we browsed to http://localhost, it worked fine. If we put www.contoso.dev in the hosts file, it worked. So what was going on?

Turns out, SP2 added a new protection against reflection attacks. Namely, SP2 no longer allows authentication to be performed across the loopback interface if the name does not
match the name of the local machine. This can be disabled a couple different ways:

Disable the loopback check completely by adding the following registry key (requires reboot):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\DisableLoopbackCheck
This key should be a REG_DWORD and set to 1
Instead of opening it up to any hostname mapped to 127.0.0.1, you can limit the hostnames allowed by adding each hostname to the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\BackConnectionHostNames
This key should be a REG_MULTI_SZ and set to the host name you are using.

Probably the safest is to add www.contoso.dev to the second registry key.

A ton of thanks to Kyle Terns, a support engineer on the IIS team for the help in tracking this one down.

UPDATE: Looks like there is a KB Article on this now (896861)

Winforms and threading

ddysart — Tue, 04 May 2004 19:33:00 GMT

There has been a recent discussion internally amongst the ADC’s in my region* about threading and WinForms. I originally cut my teeth in Windows programming by writing a multi-threaded NT Service that ran on a Alpha based Windows NT 3.51 system (who coined the term “Wintel”? I had a copy of Visual C++ 4.0 for MIPS and DEC Alpha – definitely non-Intel processors running Windows NT. It was the market (or lack thereof) that pulled support for those processors). So I learned early on about the joys of mutexes and critical sections. All that learning went away as I moved to more lucrative Visual Basic 5.0 & 6.0 work and the multi-threading center of my brain became “soft”. The recent mental exercise of tackling threading issues in WinForms has been great fun.

The challenge with WinForms is that underneath it all, all of the System.Windows.Forms.Button’s and stuff are Windows® intrinsic windows. These can only generally receive messages on the thread that they were created on, so if you are performing some really long operation (say, calling a web service – or in a demo calling System.Threading.Thread.Sleep(5000);) that thread cannot process messages for the UI. This manifests itself as an unresponsive application; several portions of the screen won’t paint, mouse clicks don’t register right away, and the user finally closes the application and sends us a min-hang dump via the “you closed an unresponsive application” dialog. The best solution to this is to make your web service call (or whatever was taking so long) on another thread. There is an excellent article by Ian Griffiths in the June 2003 issue of MSDN Magazine (also online here) on how to do this.

More or less (read: a highly simplified way of explaining this is), you define a delegate with the method signature you want to execute on another thread. The create an instance of that delegate pointing to the method you want to run and call delegatename.Invoke passing an AsyncCallback object. Your method then runs on a thread from the managed thread pool, and when the method completes it will call into the AsychCallback method. Here you must call EndInvoke which will not only clean up a lot of the thread stuff, it will return the return value of your method. Keep in mind you are still running on the thread pool thread, so you cannot update the UI directly. You need to use the Control.Invoke method to marshal your call back to the UI thread. Some code may help explain this.

private void calcBtn_Click(object sender, System.EventArgs e)
{
    string input = "On UI Thread";
    this.resultLbl.Text = "";
    
    DoWorkDelegate work = new DoWorkDelegate(DoWork);
    work.BeginInvoke(input, new AsyncCallback(WorkDone), null);
}
public delegate string DoWorkDelegate(string input);
public string DoWork(string input)
{
    System.Threading.Thread.Sleep(5000);
    return "Returned from thread: " + input;
}
public void WorkDone (IAsyncResult iar)
{
    AsyncResult ar = (AsyncResult)iar;
    DoWorkDelegate myThreadProc = (DoWorkDelegate)ar.AsyncDelegate;
    string result = myThreadProc.EndInvoke(iar);
    UpdateUIDelegate updateDelegate = new UpdateUIDelegate(UpdateFromWork);
    object [] args = {result};
    this.Invoke(updateDelegate, args);
}
public delegate void UpdateUIDelegate (string updateStr);
public void UpdateFromWork (string updateStr)
{
    this.resultLbl.Text = updateStr;
}

If you set break points in the various methods and watch the “Threads” window in VS.NET, you’ll see what code is being run where. Something to note is that you should see a two threads running, however some of us have sometimes observed an extra thread with no code associated with it (this is what sparked our discussion to begin with). Nobody seems to know what this thread is, and a dump using ADPlus shows that it is not actually there. We are chalking it up as a weird VS.NET bug – if someone has a better explanation, I’d love to hear it. Many thanks to Brian MacKay for showing me how to do this sort of work with delegates.

* Geographically speaking, I am part of the Central Region of the US subsidiary (there are two others, aptly named East and West). This is about as far as the services organization (meaning Premier Support and Microsoft Consulting Services) in Microsoft get broken down. The sales organization does go one level of granularity further into districts. Services used to align to districts, but a re-org a year or two ago rolled us up into a regional model. District-wise, I’d be considered in the Midwest district which is Wisconsin, Illinois, and Indiana.