Very weird problem on Windows Vista and Windows 7

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.



  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

    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

    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.


  1. Pierre says:

    It sound’s like a bug (maybe feature) i found on the Android platform.
    If a folder/photo album contains “part” in its name,
    it’s invisible to the phone/media manager 😛

  2. Dan says:

    Sounds like you hit a “shim”… a feature of Vista/7 that fixes compatibility for broken applications by changing the way the OS interacts with those specific applications. For example, if an API changes in Windows to fix a bug, if a few applications relied on this bug a shim can be used to allow these programs to keep working by emulating the effects of the bug, but only for those programs (so developers of new apps don’t have to worry about it).

    For example, if Windows detects you’re running an NSIS installer, UAC will try to elevate it (unless the installer contains an assembly manifest explicitly indicating whether it wants to be elevated or not… newer NSIS builds support specifying this setting in NSIS scripts.).

    You can test my theort using the method outlined here, if you think it’s worth checking out:

  3. Babutz says:

    What I know is that when an exe file has “setup” or “install” in it’s name, then an implicit elevation request is triggered (when as per default UAC and this particular setting aren’t turned off).

  4. SelfMan says:

    Might be a similar problem to this
    I’ve been hunting the crashing services.exe on lsass for 2 days before I got to the solution. And guess what, its 3 years since the KB article and the bug was NOT FIXED.

  5. Matt says:

    I wonder if ‘launch’ in the filename is triggering the ‘Installer Detection Technology’ in UAC (see ), and being affected by it?
    I couldn’t see a “requestedExecutionLevel” in the manifest for NirLauncher.exe (using Sigcheck from to dump the manifest), perhaps this is a strange side-effect?

  6. best let alone says:

    typical MS
    “only we can write code”

    did anyone ever investgate Cutler for stealing VMS source to start NT?

    Next blogger: “huh?”

  7. Dan says:

    Matt, Babutz: Like I said, shims.

    NirLauncher has a manifest but it doesn’t contain a requestedExecutionLevel directive. That may solve it, or maybe not. I’m not familiar with working with shims myself.

  8. Dan says:

    Oh I didn’t see the update… try embedding the application compatibility information in the launched executables as well as the launcher… after my first post I realized that maybe Windows realizes (correctly) that NirLAUNCHer.exe launches other apps and it shims THOSE LAUNCHED APPS for whatever reason.

  9. eliyahu says:

    Nir, it sounds like you’ve discovered a local buffer overflow in windows 7. Run OllyDbg, and see if any stacks are overflowed with your code. You could publish a Proof-of-Concept.

  10. elegiya says:

    Not so surprised. Try to create folder with the name “con”. You cannot.

  11. Bezzerwizzer says:

    *ATISHOO!* eleya, try to perform the following command. You cannot:
    format %SystemDrive%

  12. thameem says:

    i have a similar problem. in windows 7 i am trying to run an exe with exe name as “LAUNCH” and the exe doesnt work properly. Dont know the reasons there off

Leave a Reply