Have you implemented software restriction policies in Active Directory only to find that they stop working a few months later? Initial investigation may show the executable to still be blocked in the Group Policy - while the same executable now runs just fine on user desktops. This is because Microsoft’s software restriction policies are usually specific to the version of the .EXE file. I’ve heard all sorts of explanations for this, usually related to not wanting to block the function of service packs and other vital updates due to “overly restrictive software policies”… The truth is that Microsoft was smart enough to block program .EXE’s based on a hash value generated when the program was compiled from the prgrammers’ code - which means that changing the filename will not circumvent a software restriction policy.

This article is based on a recent, real-life scenario using the Internet Explorer executable, “iexplore.exe”, as the blocked program. The recent release of the IE 7.0 beta software and some freetime playing around by one of my client’s employees provided a chance for plenty of hours watching ESPN and YouTube videos on a warehouse floor and even slowdowns in getting and filling order downloads because of the use of all WAN bandwidth.

To troubleshoot failed software restriction policies I prefer to start on the client machine. To determine both whether a policy is applied correctly and the version of an executable blocked by software restriction:

• Open regedit
• Open the following key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\
• Inside that key will be one or more numbered branches related to the software restriction policies applied to that machine. To see what program each policy covers, open the numbered branch, then open the Hashes branch and click on each GUID.
• Inside each GUID key will be a string value with the data “program.exe (#.#.####.#) … and so on”. The numeric value #.#.####.# describes the program version. In my case the policy applied to “iexplore.exe (6.0.2900.2180)”
• Then, go check the version of the same executable that’s now installed on the system. In this case, I right-clicked on the iexplore.exe file and selected “Properties” and then the “Version” tab. Right at the top was the file version: 7.0.5335.5.

In this case, that was the answer - the IE 7.0, iexplore.exe was blocked with a new policy and everything was back to normal. In case the solution isn’t that simple, the best thing to do is to gether more data. Enable software restriction policies advanced logging by reopening the registry and:

• Navigate to the following key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\
• Create a new string value named LogFileName
• Enter the full path and filename of a text file that can be used for logging, ie: C:\sres_log.txt

Now, every executable run on the system will be logged to the file with a reason for wy it was or wasn’t allowed to run. Details include the executable name, PID number, GUID, path name, and an allowed/disallowed/unrestricted comment with a short reason why. Since EVERY program is logged each time it is run, the log can get quite long. To keep it from getting out of control, either disable advanced logging by deleting the key or add a batch script that will truncate the log file periodically.

The newest Microsoft security fix MS06-015: titled “Vulnerability in Windows Explorer Could Lead to Remote Code Execution” breaks “My Documents” access and features in IE, Office, Explorer, nVidia, Roxio, and several other 3rd-party applications. The official hotfix for the security fix is Microsoft KB article #918165 and lists the symptoms below as indicating you will need to install it:

• Unable to access special folders like “My Documents” or “My Pictures”.
• Microsoft Office applications may stop responding when you attempt to save or open Office files in the “My Documents” folder.
• Office files in the “My Documents” folder are not able to open in Microsoft Office.
• Opening a file through an application’s File / Open menu causes the program to stop responding.
• Typing an address into Internet Explorer’s address bar has no effect.
• Right-clicking on a file and selecting Send To has no effect.
• Clicking on the plus (+) sign beside a folder in Windows Explorer has no effect.
• Some third-party applications stop responding when opening or saving data in the “My Documents” folder

Unfortunately Microsoft neglected to mention several of the third-party apps that are also broken by this hotfix. These include, but probably aren’t limited to: nVidia drivers with shell extensions, Roxio DragToDisc or Adaptec DirectCD, Hewlett Packard’s Share-to-Web software, Kerio Personal Firewall, and SolidWorkds 3D CAD products. Thankfully someone else has spent the time on the phone with Microsoft tech support to resolve these issues and posted the registry fixes not included in KB #918165.

From Windows 95 to Windows XP & Vista the “Unhandled Exception 0×80040707″ error message, pictured below, typically occurs during the installation or update of PC software. The error code is typically associated with the installation program InstallShield, which software vendors wrap around their own software packages so they can install to Windows without interferring with existing software. The error was typically associated with the paths to Shell folders in Windows (ie: the Desktop, Programs, and Startup Menu folders in a user’s or the “All Users” profiles) - there is a detailed description of changing or recreating these paths at InstallShield’s site.

The 0×80040707 error code has become more common recently, as the Data Execution Prevention (DEP) controls (screenshot link) installed by Windows XP SP2 also interfere with InstallShield’s operations and can block its access to the Windows shell folders mentioned earlier. If your shell folder paths are all correct, the likely culprit of the error is Windows’ DEP and these steps should resolve the issue:

1. Find the primary installation file for the program you were installing. If it’s not a single-file installer it’s usually “setup.exe” on a CD, but you can either check the AUTORUN.INF file to see what program it’s calling or dig through the folders on the CD (/bin/, /eng/, and /driver/ are common folders where the true installer program is nested when the setup.exe is just a fancy GUI program).
2. Right-click the installation program and select “Run As…”. If it doesn’t show up the then file may not be an executable > start over at step #1 and look for other files.
3. Uncheck the “Protect My Computer And Data From Unauthorized Activity” box, this deactivates DEP for this executable and its child processes, and click the “OK” button.