Tuesday, July 26, 2005

Windows XP automatically tries to search when you click a folder

A friend of mine came to me with this issue, and after a bit of searching, I came across http://windowsxp.mvps.org/searchwindow.htm . Running "regsvr32 /i shell32.dll", as suggested by that site, fixed his problem, so I figured I'd repost it here, since it took me a while to find:

The following is from http://windowsxp.mvps.org/searchwindow.htm:

If you double-click a drive or folder, Search Companion may start and the drive or folder may not open. 'Search' will be the top most in the right-click context menu for a folder or drive. This usually happens if you've edited the File Folder or Drive via the Folder Options File Types dialog, in order to add a context-menu item such as "Command Prompt here", "Print Directory" feature for folders or drives.


Quick fix

Click Start, Run and type this command:

regsvr32 /i shell32.dll
(Tip from David Candy)

To fix the problem manually, open Registry Editor and navigate to:




  • In the right-pane, locate and click the (Default) value under the keys mentioned above

  • Click Modify on the Edit menu.

  • Type the word none in the Value data box, and then click OK.

  • Exit Registry Editor.

Windows (WSH) Shell Login scripts won't run after allowing specified programs

In an attempt to lock down some workstations that were having spyware trouble, I made use of the Windows 2000 "Run only allowed windows applications" option in the Group Policy Object. [Note: this feature is expanded in Windows Server 2003 as "Software Restrictions Policies" in the GPO editor, but the idea is the same]. Since the network users only use a handful of applications ( MS Word, Internet Explorer, etc ), I was able to specify these as allowed programs, disallowing everything else. However, even if I specified my login scripts in the "allowed programs" list as my_script.vbs, they still weren't running. On a hunch, I added wscript.exe, the interpreter for VBS scripts, to the allowed program list, and everything ran fine after that. I also allowed sndvol32.exe (which will allow users to access the sound mixer to change their volume), calc.exe, notepad.exe, mspaint.exe, and a few other various windows "accessories" that everyone should have access to.

Bottom line:
Can't get VBS scripts to run due to having specified an allowed list of windows applications? Try adding wscript.exe to the list.

Users restricted from changing their volume settings for the same reason? Try adding sndvol32.exe.