NirBlog

When I released the first Beta of NirLauncher package, I warned you to avoid from running NirLauncher as Administrator on Windows Vista/7, because if you do so, launching a few of my utilities, like Network Password Recovery and   LSASecretsView,  may cause a crash in lsass.exe and then an automatic system restart.

After running some tests and researching  this problem, I found out a workaround, but a very weird one.  This problem can be solved simply by changing the .exe name from NirLauncher.exe to another name that doesn’t contain the word “Launch”.
Yes, you probably think that I’m crazy,  but until now I tested this issue in 3 different systems (one with Windows 7 and 2 with Windows Vista), and in all 3 of them changing the .exe name really solved the crashes problem.

If you still don’t believe it, you are welcomed to test it on your own Windows Vista/7 machine and see if you get the same results, but… Be careful and be aware that this test may crash the lsass.exe process and then restart your system.

Here’s the instructions for testing this weird issue:

1. Download the last build of NirLauncher package from here.
2. Extract the package into any folder you like. You must extract the package with folder names, so all files under NirSoft folder will be extracted into NirSoft subfolder.
3. Right-click on NirLauncher.exe and choose ‘Run As Administrator’.
4. Go to the ‘Password Recovery utilities’  tab, and run the ‘Network Password Recovery’ or ‘LSASecretsView’ utility.
   

   NirLauncher

5. Wait a few seconds, and then you should get the following crash message: “Windows has encountered a critical problem and will restart automatically in one minute. Please save your work now.” If you don’t get this crash message, try to run the other utility.
   

   Windows Crash

6. Wait a minute until the system restart. After the system reboot, Go to the folder of NirLauncher, and then rename NirLauncher.exe to NirBauncher.exe and NirLauncher.cfg to NirBauncher.cfg  (B instead of L)
   You can also rename it to any other name, as long as the name doesn’t contain the word ‘Launch’. Also, the name of the .exe file must be identical to the .cfg file, because NirLauncher reads the .cfg file according to the .exe name.
   

   Rename NirLauncher.exe to NirBauncher.exe

7. Now, right-click on NirBauncher.exe and choose ‘Run As Administrator’.
8. From NirLauncher interface, run the same utility that previously caused the system crash.  The utility should run properly without any crash. At least that what’s happen in the systems that I tested until now.

To ensure that this weird problem is not caused by something bad that I did inside NirLauncher, I also created a small program in c++ that only executes my ‘Netword Password Recovery’  utility (netpass.exe) with CreateProcess API and then exit. The tests with this small .exe still bring the same results: When the .exe file contains the word ‘Launch’, system crash is occurred, and when the .exe file doesn’t contain the word ‘Launch’, everything works fine.

The systems that I used to test this problem don’t have any installation of Antivirus, Firewall, or any other software that might affect the operating system behavior. So I guess that there is some code inside Windows kernel which says, “If the .exe contains the word ‘launch’, execute it in a different way than all other executable files.”

However, I can’t find any reasonable explanation for adding this .exe filename condition into Windows operating system. If you have any idea or information about this weird bug, you are welcomed to add your comment.

Update (November 28th):  Thanks for Dan about the writing the Shim comment. The problem is really the caused by Application Compatibility Engine. From some reason, when the .exe file contains the word ‘launch’, the Application Compatibility Engine consider the application as not compatible with Windows Vista/7, and thus the application is “shimmed”, which means that apphelp.dll and AcLayers.DLL are loaded and replace some API calls of Windows in order to resolve compatibility issues.  In my case, this  Compatibility Engine doesn’t solve compatibility problems… it actually creates the problem.

According to some Blog posts and documentations, embedding a Manifest inside the .exe that contains application compatibility information should disable the shimming and solve this problem, but… I tried it and unfortunately it doesn’t work.  However, because I already know which component cause the problem, I’ll eventually find a way to bypass it.