Moving blog

I'm moving the blog over to Wordpress - http://frodelillerud.wordpress.com.

Ooh, bluescreen!

The old trusted IBM T42 laptop started acting up a couple of weeks back, and....well, to make a long story short, I got a new laptop the other day. A Lenovo SL500 x64 with 4GB RAM. The Vista Home edition lasted about 10 minutes before I wiped the machine and installed Windows Server 2008 x64 instead.

I've been running Server 2008 on my previous laptop for about 6 months, and have no complaints at all. So the choice was obvious for this machine as well, only this time I have installed the x64 edition instead.

I downloaded all the relevant Vista x64 drivers from the Lenovo driver page, and got the machine up and running.

Now, after about two weeks I've had a total of three bluescreens. Which is quite a lot. The first one was when I ran TaskInfo, a rather old competitor to Process Explorer. I assumed it was just the application.

The second bluescreen was when I was working against our terminalserver at work. The local machine didn't really do any work exept communicate through RDP. Today, I got a new one. I was surfing the web, programming Visual Studio and copying a large file from another machine.

What the ** is going on here?

All the bluescreens complained about DRIVER_IRQL_NOT_LESS_OR_EQUAL, which basically means that a driver attempted to access memory location it does not have permission for, or the driver tried to access another process where the Interrupt Request Level on the other process is higher than it's own. This page has good info about the various Stop-codes.

Inspired by Mark Russinovich's blog I opened up WinDbg, and opened the crash dumpfile C:\Windows\MEMORY.DMP. Here is the result:

So it points directly at the driver NETw5v64.sys. A quick search reveals that this is the driver for the Intel WiFi 5100 WLAN card. Which sounds reasonable enough - I was using the WLAN card in both of the last two bluescreens.

Still, it's always good to doublecheck the stacktrace by clicking the "!analyze -v" link.

Here we see that KeBugCheckEx, (a standard Windows method in the kernel which "brings down the system in a controlled manner"), was called, and it was initiated by code inside the NETw5v64 driver.


I opened up the Server Manager->Diagnostics->Device Manager, and checked the current version of the driver installed. It was v12.1.0.14 from 28.august 2008, about 5 months old.


Checking the Lenovo website again I verified that they hadn't updated the driver since 29.aug.

Instead I went directly to Intel's driverpage, and found version v.12.2.0.11 from 17.nov 2008. Yet another example where the laptop supplier is unable to keep up with the newest driver versions.

Hopefully the bluescreen problem is solved now. Time will tell.

Exchange 2007, ActiveSync and SSL certificates

We're currently rebuilding our entire serverpark at work, and making the transition from Windows Server 2003 and Exchange 2003 over to Windows Server 2008 and Exchange 2007.

One of the features we want to implement is the ability to have secure communication between our mobilephones and Exchange. This means moving the traffic from port 80 over to port 443 using a SSL certificate.

After googling around we decided to purchase a SSL Certificate from GoDaddy.com. It's a horrible, horrible website, but the certificate is only 30$/year.

The experience of getting a Certificate, and installing it on the Exchange server is like poking a thorn in your eye. After combatting our way through the GoDaddy site we finally got our .crt file.

From the net we found out that we need to run PowerShell commands on our Exchange server to install the new certificate. At this point we used a while to understand that there is a difference between the PowerShell that is native to Windows Server 2008, and the PowerShell found in Start->Programs->Microsoft Exchange Server 2007->Exchange Management Shell.

In that shell we used the following commands:

Import-ExchangeCertificate -path C:\SSL\secure.oursite.no.crt

dir cert:\LocalMachine\My | fl

From the last command we copy the thumbprint to the clipboard, and use it in the next command.

Enable-ExchangeCertificate -thumbprint A3E7DCBF02A0DA34...removed...AB  -services "IIS,SMTP"

Also we made some changes in Exchange Management Console according to this article.

On our mobilephones we've changed the address to secure.oursite.no, and ticket on the SSL checkbox. The first time we sync the phone it asks if it's ok to use secure features, and after accepting it works just fine.

Edit:
After starting up the Outlook client we started getting warningmessages that the sertificate on the server did not not match the URL we used to access the server.

The problem was that the server was handing out the secure.oursite.no certificate, but out mail clients were connecting to the internal servername, exchange.geas.local. The problem was fixed by telling the Exchange server to use our external name instead.

We followed the approach described by John Webber in this forumthread.

Slow Run dialog

Over the last few months I've been getting better at using hotkeys for navigating around. One of my most used ones is Windows+R, which brings up the Run dialog.

But every once in a while it's dead slow. So slow I begin to think "did I really press those buttons?" and I press them again. And again. After 10-11 seconds I get four or five Run dialogs up at once. The problem comes and goes. Some evenings it happens all the time, but then it can take days or weeks before I see the problem again.

Today it came back, and I decided I wanted to find out what causes it. I'm having a presentation in a few weeks and don't want to have it popping up during the live demos.

I started up Procmon and began to capture events as I pressed Win+R. After a lot of filtering I found a line with the result set to "BAD NETWORK PATH". Hmm. Sounds suspicious. The path it was trying to open was \\server\employees\frode, which is the domaincontroller at work.

Ok, that sounds reasonable enough. For some reason it's trying to contact the domaincontroller whenever I open the Run dialog. My first thought is that the historylist contains a reference to that server, but after reviewing the list I could not find anything particular. I removed the history list completely by renaming the registrykey HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU. The historylist is now empty, but still it would take about 10 seconds to open the dialog.

I recognized the path it was trying to open as my %HOMESHARE% path. Opened up cmd.exe, and ran the Set command. Amongst the variables I saw the following three:

HOMEDRIVE=Z:
HOMEPATH=\
HOMESHARE=\\server\employees\frodel

Hm, Z: is a mapped drive to the server at work. When I left work today I put my laptop in Hibernate mode by just closing the lid, and it's just been awaken again here at home. So that means that Z: is still my homedrive, but that is not an accessible drive from home. Z:\ is still a mapped drive, but not a functional one.

In cmd.exe i tried the following, and received an errormessage 10 seconds later:

C:\>%HOMEDRIVE%
The network path was not found.

I think we're getting somewhere!

Rebooted the computer, and this time the environment variables were set like this:

HOMEDRIVE=C:
HOMEPATH=\Users\frodel

The Run dialog is now 100% responsive, and I'm pretty sure it was because %HOMEDRIVE% and %HOMESHARE% was referring to the server which wasn't available.

Using state server with ASP.NET

At work we deal a lot with the web version of SuperOffice CRM, and lately I've been trying to figure out why one of our customers users keep getting logged out all the time. Through a dialog with the core technical persons at SuperOffice we've tracked it down to the Session being lost.



Most likely the session is lost because the Application Pool is recycled for some reason. There are several thing which could cause such a recycle.
- web.config being changed
- files in \bin or \App_code directories are modified
- any of the conditions in Process Model for the Application Pool is met. Like a memory limit being hit, or a request-queue being full.
- antivirus or similar modifying the above files

Because of all of this I've researched what it takes to move the session state handling out of the w3wp.exe process, and it's actually not that difficult.

Session state can primarily be handled in three ways. In-Process, with State server or in SQL server. There is also a Custom way, but that's out of our scope for now.

Moving from In-process to using the State server is as easy as modifying a single line in your web.config, and making sure the Windows Service called ASP.NET State Service is running. The web.config should include a sessionState element, like this.

<configuration>
<system.web>
<sessionState mode="StateServer"
             stateConnectionString="tcpip=127.0.0.1:42424"
             cookieless="false"
             timeout="20">
</sessionstate>
</system.web>

And that's it!

What we've gained by doing this is that the changes listed above will no longer cause a user to be logged out. You can even call iireset.exe, and the session is still kept alive. What we've lost is about 15% performance since the session needs to be serialized out from the w3wp.exe process, and handled by the aspnet_state.exe process.

If the ASP.NET State Service is restarted it will loose all the sessions since they are kept in-memory by the service.

We can also take this one step further by storing the sessions in a SQL database instead. By doing this we gain even more recilience because we can reboot the server which handles the sessions, and users are still maintaining their sessions when the server is online again.

In order to set up SQL handling of the sessions you'll need to modify the web.config again, but also have a SQL database to store the sessions in.

<system.web>
<configuration>
<sessionState mode="SQLServer"
             stateConnectionString="tcpip=127.0.0.1:42424"
             sqlConnectionString= "data source=127.0.0.1;
                                   user id=sa;password=secret"
             cookieless="false"
             timeout="20">
</sessionstate>
</system.web>
</configuration>

And the SQL database is created by a tool that ships with the .NET Framework.

C:\>aspnet_regsql.exe -S localhost -U sa -P secret -ssadd -sstype p

That command will create a database on the local SQL server called ASPState where all the sessions are stored. The drawback of storing sessions in SQL is that you loose about 25% performance compared to the InProc mode.

Cosmos is expanding

I've been putting down a lot of time working on the Cosmos project over the last few months, and it's fun to see all the progress we've been making.

The network driver for the RTL is complete enough to send and receive the data we want, and currently further development for RTL and UDP is continued by Chad Hower (here and here).

I've moved over to filesystem, and am working with the Virtual Filesystem layer. Currently it's working on top of the Ext2 filesystem, but the purpose of this layer is to be filesystem independent. We can enumerate directories and files using classes in the System.IO namespace, but I haven't begun to read inside files yet. For that we are going to need support for Streams.

Often during the development I come across certain basic parts of the .NET framework which break our build, so I keep going back to the absolute basics to fix those as well. As an example I added lots of Console.Write and Console.WriteLine overloads, since we were unable to print lots of basic types. Today I fixed Boolean.Parse(string) and Boolean.TryParse(string, out bool).

I believe it's important to get all this basic functionality in place as well, not just features like network, filesystem and compilation speed. It'll be a lot easier for newcomers to get started if we have all the basics in place.

Flashing my new BIOS's

My stationary computer started acting up and would not let me reinstall an operating system on it a couple of weeks back. After replacing most of the peripheral devices without any luck I decided to buy a new motherboard, CPU, RAM etc.

I ended up with a Gigabyte MA790FX-DS5, running a AMD Phenom 9850 and 4GB of Corsair RAM. I choose a low end videocard, Sapphire Radeon HD 2400, since I'm not much of a gamer anymore.

The Radeon card seems to be non-compliant with my Dell 20" monitor, and refuses to display an image using DVI cable. I got it working with a S-VHS cable, but the graphics are horrible. I see that Sapphire has released a new BIOS for the videocard claiming to "(...)fix bug with Samsung DVI-D(...)". Hopefully it'll also work with my DVI-D monitor.

Flashing a BIOS isn't always straightforward. Finding out HOW you flash, that is.
After googling around I found a way to flash my motherboards BIOS, and I'll put the receipe here for my own future reference.

I tried using the @BIOS application to flash the Gigabyte card. Didn't work. Couldn't connect to any of the online servers.

I also tried the ActiveX driven Download Center on the Gigabyte website. No luck.

Here is what I ended up with:
1. Download new BIOS from MA790FX-DS5 page. My old BIOS was F5, and the newest available was F6.
2. Extracted the files onto a floppy disk.
3. Rebooted computer and pressed END to get to QFlash application.
4. Choose floppy drive, and the .F6 file.
Flashing complete.

Now for finding out how to flash the ROM on the Radeon card.