NirBlog

Notice:  The latest version of NirLauncher package is now available at http://launcher.nirsoft.net/

Many people ask me to add ‘Auto Update’ feature that will automatically update the latest version of all NirSoft utilities and the NirLauncher itself.  So I’ll eventually add this feature in one way or another, but the first step is to create an official download page of NirLauncher package that will be updated with the latest utilities every week or every 2 weeks. I hope that the official download page will be available in the incoming weeks.

For now, there is a new Beta download of NirLauncher package, with the following changes:

• Fixed the missing icons problem in Windows 7/x64.
• Added packages menu to choose a package.  A package can also be selected from accelerator keys (Ctrl+1 for the first package, Ctrl+2 for the second package, and so on…)
• Added status bar information.
• Fixed the crash problems that occurred in some utilities on Windows 7/Vista, when running  NirLauncher as administrator.  This problem occurred only because the executable of NirLauncher contains the word ‘launch’. You can read more about this problem in this post.
  Here’s a small summary of the problem and the way that I solved it:
  • When any executable contains the word ‘launch’ (in my case, NirLauncher.exe), Windows Vista/7 automatically shim the application, which means that apphelp.dll and AcLayers.DLL are loaded into the process and replace the pointers to Windows API functions inside the export table.
  • When  NirLauncher run a utility, the utility is also shimmed, probably because child applications automatically get the same treatment like the parent application. However, if the utility requires elevation (To run as admin) while NirLauncher was executed without admin rights, the launched utility is not shimmed.
  • Some of NirSoft utilities –  ‘Network  Password Recovery’, LSASecretsView, and LSASecretsDump use some code injection technique in order to extract the system data. These utilities use the API function addresses returned  by GetProcAddress function to execute the desired code in a system process. But… when an application is shimmed,  GetProcAddress function returns the addresses of the shim layer instead of the real kernel addresses. These wrong addresses caused the system process to crash immediately and restart the system after a minute.
  • The easiest solution for this problem is to change the executable name of NirLauncher to something else, but this kind of solution is really ridiculous. Also, I cannot assure that Windows won’t shim my application from any other reason.
  • I also tried to add into the executable of NirLauncher and the other utilities a manifest which contains compatibility information. This manifest is a small XML which says to Windows OS: “This application is compatible with Windows Vista and Windows 7, so don’t shim it”.
    Unfortunately, this solution simply didn’t work.
  • The problem was finally solved by making changes in the problematic utilities (NetPass,  LSASecretsView, and LSASecretsDump), so these utilities will work properly even when they are shimmed.  When these utilities detect that they are shimmed, LdrGetProcedureAddress (in ntdll.dll) function is used to get the real address of GetProcAddress function inside the Windows kernel, and in this way, my utilities  bypass the shim layer and get the real kernel addresses.

Update (December 1st, 2009):  Fixed also the Shim issue in MessenPass and WirelessKeyView.

Download the third Beta of NirLauncher package with more than 100 utilities

Zip File Information:  (to verify that the downloaded file is Ok)

MD5: c181e7e46d4acde6f6c9b12309eb85b8
SHA1: 580fcb82d057c8a3cef752124802026886956172
File Size: 6,908,394
Number of files in the Zip: 247

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.

Many users of  SearchMyFiles utility complained that it’s hard to work with this utility, because after getting the search result, it doesn’t allow to do some basic operations on the search result, like deleting files, cut and paste, rename, and so on.
So the new version of SearchMyFiles now allow you to do these basic operations, similarly to the search result of Windows search. Be aware that the context menu of SearchMyFiles still doesn’t provide all options of Windows Explorer context menu, but I gradually improve it in future versions.

Here’s the list of all changes in the new version of SearchMyFiles utility:

• Added ‘Reset To Default’ button that allows you to easily reset the ‘Search Options’ dialog-box.
• Added ‘Open File On Double-Click’ option. When this option is checked, double-clicking a file will open it with the default program, like double-click in Explorer.
• Added new actions that you can make on the selected files of the search result: Explorer Cut, Delete, Move To Recycle Bin, and Rename.
• In the search option of file times, added ‘Today’ and ‘Since Last Reboot’.
• Added most-recently-used (MRU) list in combo-boxes of the search dialog-box. SearchMyFiles automatically remembers the last 10 strings that you used for every field, and allows you to easily select them from the Combo-Box. If you don’t want that your last search strings will be saved in the .cfg file (from privacy reasons), you can select the “Don’t Save MRU Lists” option in the Options menu.
• Fixed the ‘Subfolders Wildcard’ issue according to users request. Just for example: In previous version, if you tried to search in c:\ with abc*.* as subfolders wildcard, and you had a folder in c:\hello\bbbbb\abc123, SearchMyFiles utility didn’t search in this folder even when abc123 folder matched the folder name, and that’s because the folder below, bbbbb, wasn’t match the subfolders wildcard. Starting from this version, SearchMyFiles scan all subfolders, even if they don’t match the wildcard, but the actual file search is only made for subfolders that match the subfolders wildcard.

The new version of SearchMyFiles is available to download from here.

• ShellExView:
  • On x64 systems, ShellExView now always shows the shell extensions for x64 applications, even on the 32-bit version of ShellExView. If you want to get the shell extensions list for 32-bit applications, use ShellExView with /wow64 command-line option.
  • Added /remote command-line option, which allows you to view/enable/disable shell extensions in a remote computer on your network.
• MozillaCacheView and ChromeCacheView:
  • Fixed a bug that caused these programs to fail with copy of files from the cache when the filename contained invalid file characters (?, :, *, |, and others).
• WirelessKeyView:
  • Added ‘Use code injection method’ option in the Advanced Options window, as a workaround for using this utility on Windows 7.
• USBDeview:
  • Fixed bug: USBDeview displayed wrong drive letters when the serial number or ParentId Prefix contained only one character.
  • Added a separated version for x64 systems, in order to allow you to disable/enable items on x64 systems.
• MyUninstaller:
  • Added support for x64 installations.
• OpenedFilesView:
  • /filefilter command-line option now allows you to specify a filename without a path. For example, if you run OpenedFilesView with ‘/filefilter index.dat’, all opened index.dat filenames will be displayed.
• HashMyFiles:
  • Added ‘Delete Selected Files’ option, which allows you to easily delete duplicated files.
• FileTypesMan:
  • Fixed issue: When UserChoice is selected, FileTypesMan now displays the right file type properties loaded from the UserChoice application key.
  • Fixed issue: When UserChoice is selected, the ‘Open File Type In RegEdit’ option now opens the right UserChoice application key.

Notice:  The latest version of NirLauncher package is now available at http://launcher.nirsoft.net/

4 weeks after the first Beta release of NirLauncher utilities package, a new release is now available to download. If it’s the first time that you read about this package, it’s recommended that you also read the release notes of the first NirLauncher release, here.

The following changes were made in this release:

• Fixed bug: NirLauncher failed to execute console application when the path contained spaces.
• NirLauncher.exe is now on the root folder, while the NirSoft utilities are under NirSoft folder. Be aware that you must extract the package with the same folder names in the zip file. Otherwise, it won’t work.
• Added autorun.inf in the root folder that allows you to automatically open NirLauncher when you plug the USB flash drive. (Doesn’t work on Windows 7, because Microsoft removed this feature)
• Added ‘All Utilities’ tab that show all utilities in one list.
• sysinternals2.nlp is now available with full URLs, thanks to the great work of Yair from the comment in the first Beta post. Also, added ‘All Sysinternals Tools’ tab.
• Add Next/Previous Package buttons.
• Added option to add a tray Icon (Disabled by default).
• The new utility, DevManView, added to the package.

Download the second Beta of NirLauncher package with more than 100 utilities

Zip File Information:  (to verify that the downloaded file is Ok)

MD5: a617cfa78c138c340ec99de6f5d63903
SHA1: fa0a8fab272289edeede32d190b4c0862216b0cb
File Size: 6,812,717
Number of files in the Zip: 246