Update Kills VHD Boot (Temporarily)

Some windows update that got installed on my VHD-based Windows in week from 2011-06-12 to 2011-06-19 killed possibility to boot from them. Instead of normal startup procedure I was greeted with Repair Windows.

Fortunately I had another Windows installation on same machine so I was able to check boot parameters:

bcdedit

 Windows Boot Manager
 --------------------
 identifier              {bootmgr}
 device                  partition=D:
 description             Windows Boot Manager
 locale                  en-US
 inherit                 {globalsettings}
 default                 {current}
 resumeobject            {fa179570-87b4-11e0-b0a7-da74dade416b}
 displayorder            {current}
                         {fa179565-87b4-11e0-b0a7-da74dade416b}
 toolsdisplayorder       {memdiag}
 timeout                 1

 Windows Boot Loader
 -------------------
 identifier              {current}
 device                  partition=C:
 path                    \Windows\system32\winload.exe
 description             Windows 7 (x64)
 locale                  en-US
 inherit                 {bootloadersettings}
 recoverysequence        {fa179566-87b4-11e0-b0a7-da74dade416b}
 recoveryenabled         Yes
 osdevice                partition=C:
 systemroot              \Windows
 resumeobject            {fa179564-87b4-11e0-b0a7-da74dade416b}
 nx                      OptIn

 Windows Boot Loader
 -------------------
 identifier              {aa179565-87b4-11e0-b0a7-da74dade416b}
 device                  partition=E:
 path                    \Windows\system32\winload.exe
 description             My VHD installation
 locale                  en-US
 inherit                 {bootloadersettings}
 recoverysequence        {fa179572-87b4-11e0-b0a7-da74dade416b}
 recoveryenabled         Yes
 osdevice                partition=E:
 systemroot              \Windows
 resumeobject            {fa179570-87b4-11e0-b0a7-da74dade416b}
 nx                      OptIn

There was my problem - somehow update has changed VHD boot device to nonexistent partition E:.

Solution lies in two commands:

bcdedit /set "{aa179565-87b4-11e0-b0a7-da74dade416b}" device "vhd=[C:]\VHDs\Windows7.vhd"
 The operation completed successfully.

bcdedit /set "{aa179565-87b4-11e0-b0a7-da74dade416b}" osdevice "vhd=[C:]\VHDs\Windows7.vhd"
 The operation completed successfully.

P.S. My best is that one of following updates is the killer:

• Security Update for Windows 7 (KB2503665)
• Security Update for Windows 7 (KB2536275)
• Security Update for Windows 7 (KB2536276)
• Security Update for Windows 7 (KB2544893)

Detection of Executing Program in Inno Setup

When upgrading your application it is very good practice to let your setup program know whether your application is running. This way setup will tell you to close your application instead of requiring Windows restart.

Solution comes in form of Mutex synchronization primitive. Application will create it and hold it until it is closed. If setup notices that application already has mutex under control, it will “complain” to user. It is then user’s task to close application. It is not as comfortable as closing application automatically but it does the job.

Since we need a global mutex for this purpose, we should not use something that could get used in other application for other purpose. To me best format of name is MyCompany_MyApplication. It is highly improbable that anybody else would use it. If you want to be (almost) sure getting random string is also a possibility.

For this to work we need to tell InnoSetup which mutex we plan on holding:

[Setup]
...
AppMutex=Global\MyCompany_MyApplication
...

In application we need to use same Mutex name:

namespace MyNamespace {
    internal static class App {
        private static readonly Mutex SetupMutex = new Mutex(false, @"Global\MyCompany_MyApplication");

        [STAThread]
        internal static void Main() {
            //do some great stuff.

            Application.Run(new MainForm());

            SetupMutex.Close(); //notice that it HAS to be after Application.Run
        }
}

P.S. Why do we MUST put SetupMutex.Close() after Application.Run() is exercise left to user. I will just note that it has something to do with garbage collection.

P.P.S. While this was written with InnoSetup in mind it is also applicable to virtually all setup systems out there.

In Redmond for a While

P.S. I’ll be in a Redmond for few weeks. If you read this blog and you are near Redmond, let me know and we can have a beer.

Thanks Microsoft

I reinstalled my machine and I had to install some of my tools. To keep things simple, I just went to download them from my own site. I was somewhat surprised at a warning: “vhdattach201.exe is not commonly downloaded and it could harm your computer”. I made this program but now even I wasn’t sure whether something has gone wrong.

So I checked everything. And yes, there is nothing wrong with my programs. It is just that some fool in Microsoft decided that what we need is another warning.

I cannot even start to comprehend what this will solve. If utility with couple of thousand downloads triggers this behavior so will lot of other people’s programs. Users will see this warning couple time through day. And they will ignore it. What IE 9 brought us is just another dialog that we will not read.

Connecting Windows 7 to Old Samba Software

I got myself one simple (maybe too simple) NAS: IcyBox’s NAS902. It’s purpose was mostly just handling backups so lack of features didn’t bother me.

What did bother me was accessing this box from Windows 7. When I used NAS’ guest account only, everything was fine. When I added new SMB account with my user name and password I could not access it anymore. To make long story short, issue here was in ancient version of SMB server inside NAS902. It supported only NTLMv1 as authentication protocol. Windows 7 do not use that protocol (and for a good reason) by default. My computer and my NAS just weren’t speaking same language.

Solution was simple enough. First I had to start “Local Security Policy” (in Windows 7 it is as easy as writing exactly that in search box). From there I had to go to “Local Policies” and then “Security Options”. From list of policies I found “Network security: LAN Manager authentication level”. Changing setting to “Send LM & NTLM responses” solved issue.

P.S. Yes, I know, this lowered security in my network considerably. I need to find another NAS as a long-term solution.