Cannot set fixed IP

Funny problem: Set the fixed IP of a network interface - once you have clicked OK back out of the network interface properties dialog box, it reverts to an automatically assigned IP of 169.254.x.x. Go back into properties for the network interface, and IPv4 settings still holds the static IP you set. It is not possible to ping the interface on that address, and ipconfig shows only the automatically assigned address.

I had this problem on a Windows Server 2008 R2 today, and spent a fair amount of time troubleshooting it, including running Windows Update, several reboots etc..

Solution: In the end, I uninstalled all network interfaces found under Network Interfaces in Device Manager (right-click Computer > Manage > Devices) and then right-clicked the device root and selected "scan for hardware changes" to automatically reinstall the network interfaces. Voilla, the IP settings now sticks and actually works!

Possible reason: I am not sure what messed up the system, but my main suspect would be a special high performance frame grabber driver from Pleora that was installed on this server for two other network interfaces (not the one I was trying to set the IP on). This driver obviously digs deep into the device hierarchy, because it removes the network interfaces it controls out of the Network Interfaces tree entry in Device manager over to a new tree entry called "Pro/1000 grabber devices".

Anyways, I got my solution - now it works!

Accesing an .mdb database file fails after SQL Server upgrade

I have a feeling this is a pretty classic problem, and there's probably a variety of related problems out there - anyways, this caused me some headache today:

Scenario: I am developing an application that uses a simple .mdf database file (SQL Server Compact) to store and retreive data. The app runs well, even when taking it to other computers where SQL Server Express (SSE) is installed as a dependency application for my app. Today I installed a new version of SSE (2008 R2) on my own computer that I use to develop. Because of some clutter of old installations (2005 and 2008), I first removed the existing SSE completely, then installed the new one.

Problem: When trying to run my app after having installed the new SSE, it crashed with the following message:

Failed to generate a user instance of SQL Server due to a failure in starting the process for the user instance

At first I did a compare of the parameters used to start the SQL Server service and the SQL VSS Writer with the same services on other computers where it worked. They were identical!

Solution: This posting on social.msdn.microsoft.com gave me the solution. Since I am running Vista, I renamed the following directory (instead of deleting it, to make sure I had a safe return in case it made things worse):

C:\Users\[username]\AppData\Local\Microsoft\Microsoft SQL Server Data\SQLEXPRESS

I restarted my application, and voilla! I was back on track!

Reason: According to Scott J. Baldwin on the above mentioned posting, referring to Reen's suggestion B, "this error is often caused because the parent instance (for whatever reason) can't copy the system databases to the users local isolated storage folders. Sometimes it is because of a previous install of SQL Express has left files in that directory which is why Reen's suggestion sometimes works" - Thanks guys!

Creating an installer for your software that checks for and installs .NET and SQL dependencies

I developed a small software package for a client utilizing a SQL Server 2008 Express database and .NET 3.5 technology. The client wanted a simple installation package to distribute the software to several computers. Hence, the package should check for dependencies, like whether or not the .NET 3.5 framework and SQL Server 2008 Express was installed.

My eyes quickly fell upon the excellent Inno Setup freeware package. Together with this adaption of Inno found on The Code Project website, to include and/or download the needed dependency packages, it turned out to be the perfect tool for the job.

I had to develop a new script to be able to include the SQL Server 2008 R2 Express, SQL Compact Edition 3.5 for Desktops and MS Installer 4.5 in my package, but it was a breeze with all the good work already done. Check out my posting over at The Code Project to see these adaptions.

Change of hard drive - cloning/restoring with BartPE/DriveImageXML

The following is not particularly ground breaking, just a note to self on how to do a HDD (hard disk drive) backup and restore as hassle-free as possible. My choice of tool was a BartPE CD that I built including the disk cloning tool DriveImageXML (or DIX) as a plugin.

Making the clone file was the easy part - DIX simply lets you make a clone file to a USB drive from within a running Windows OS. Getting the new HDD to boot after restoring the clone file to it was a little trickier. This is what I ended up doing

1. Install DIX on the old drive running Windows, then creating a backup (clone) of the whole partition to a file on a USB hard drive. Yes, you can actually do that while Windows is running off of the same disk!
   
2. Removed the old HDD and installed the new HDD in the computer (since it was a laptop with only one HDD bay, I did not have the option of leaving the old one in until the data was transferred).
3. Partitioning was a little tricky. Unless you find a partitioning plugin for BartPE, you will have to do it from some other bootable media. I first tried an old Win98 command-line bootable CD, which only formatted around 130Gb (my drive was 160). I ended up booting into a Knoppix Linux boot CD and create a standard, active (=bootable) partition by running its fdisk from a command shell after issuing a su to gain administrator access. The partition was marked as a Linux type partition, which does not matter since DIX will overwrite it anyway, it just does not know how to create the partition. I might also have created the partition by booting into a Windows installation CD, creating the partition and then abort further installation.
4. Now booting into the BartPE CD, I ran DIX again on the new disk, restoring the image from my USB disk. To get Bart to see the USB disk, make sure that it is on and connected already at boot.
   
5. Booting from the new disk was the trickiest. When attempting to boot from the new disk, only a blank black page with a blinking cursor appeared. I had to boot into the Windows installation disk and choose Recovery console. From there, I ran fixboot, fixmbr and bootcfg /rebuild. Seems like my hard drive lacked both a working master boot record (MBR) and because my old disk had a utility partition that I had not bothered taking with me, the partition entry in boot.ini was also wrong.

Finally, my new disk booted with all the old data and programs as it was before.

WPF program crashes when started from within a 16-bit DOS program

Scenario: I am programming a Windows application in VB.NET using Windows Presentation Foundation. My program is going to be started from within another old-style 16-bit program, hence this starter program runs in NTVDM (NT Virtual Dos Machine - the way Windows creates backwards compatibility with Windows 3.x/MS-DOS programs). Yes, they are actually still being used out there - the app I am programming is a helper app for the medical journal system WinMed.

Problem: Starting my app by double-clicking its EXE file is no problem, neither is starting it from a command prompt - from a cmd.exe command prompt, that is. But starting the program from within the 16-bit WinMed (it has a customizable menu for starting external programs) or from a command.com (=16-bit) command prompt, immediately results in a crash simply stating: "A problem caused the program to stop working correctly. Please close the program". Why it stopped working is kept a secret.

Cause: I had a strong hunch that NTVDM has something to do with it, since starting my app from both command.com and from within the WinMed program fails. Then I found this post: The environment variable WINDIR is missing from the NTVDM environment. This can be easily checked by running a command.com window and type the set command - all environment variables are then listed. I found that no WINDIR setting was present in this list of environment variables.

Solution: To run the program from the command.com command prompt, I had to first run the following command:
set windir=c:\windows
Now I was able to start the program from within command.com. To ensure that the environment variable was always set when running NTVDM programs, I edited the c:\windows\system32\autoexec.nt file by adding the above command to the end of it - making sure I had no spaces before or after the equal sign. Now my app starts even from within WinMed!