ArcGIS Geoprocessing Tools Scripting Error

I have been frustrated by this error for quite some time now. If you are running ArcGIS 10 and use the geoprocessing tools, then you may have seen it by now.

Look familiar?

When I first started running ArcGIS 10, I was getting this error on a very regular basis.  It seemed like every other time I tried to run a tool, it would occur.  The only solution seemed to be to restart ArcMap.  At the time, I did a little searching to try to resolve the issue.  Almost every mention of this error pointed you to Esri Technical Article 38099 in reference to Bug NIM011135.  The error message shown in this article did not exactly match the message I was getting, but I applied the patch anyway.  Unfortunately, it did not seem to have an effect.  Different problem.  I also found article 38564. This error description seemed a lot closer.  I followed the instructions to reset my default programs.  This did seem to help.  The frequency of this error decreased dramatically, but it would still occur on a seemingly random basis.  My assumption was some kind of locking issue between ArcGIS and some other program as article 33792 suggested.

Over the last few weeks, however, I started to notice a pattern. It seemed to occur after I viewed the Item Description from the ArcCatalog window in ArcMap. Then, a few days ago, another instructor contacted me and wanted to know if I had resolved this issue. He said that it was showing up in class and really annoying him.  At that point, I decided to test my theory.  I opened ArcMap, viewed some metadata, tried to run a script tool, and there it was: An error has occurred in the script on this page.  I closed ArcMap, repeated the process, and same thing.  We were elated to finally know the trigger. So if you are running into this error, try this out to see if viewing the Item Description is your trigger as well.

The Item Description in ArcMap is opening in an HTML window, so I next wanted to know if opening any HTML window through ArcMap caused the problem. I tried an HTML Popup. This did not cause the error.

The next day, I did a little bit more research and testing. Once I knew what to search for, I found that someone had noticed the pattern and posted a blog article about the error in January of 2011. The solution was to decrease one's Internet Explorer security settings from the default level of Medium-high to Medium. I tried this, and problem solved. I could view metadata and then open a geoprocessing tool without error. Yeah!!!

Note:  If you want to do this, be sure to adjust the settings in the 32-bit version of Internet Explorer, not the 64-bit version.

Only one issue, I now had medium level security settings. Probably not that big of a deal for me since I do not use the 32-bit version of Internet Explorer (except in ArcMap), but this would not fly in a standard work environment.

I decided to figure out exactly which setting was causing the problem. After some experimenting, I found it. The setting Allow previously unused ActiveX controls to run without prompt needs to be set to Enable.

If you want to change this setting, then open the 32-bit version of Internet Explorer by going to Start --> All Programs --> Internet Explorer. The 64-bit version will say Internet Explorer (64-bit).  Once Internet Explorer opens, go to Tools --> Internet Options, and click on the Security tab.

For your Internet settings, click on Custom level..., and scroll down until you find the ActiveX controls and plug-ins.  Change Allow previously unused ActiveX controls to run without prompt from Disable to Enable.

Click Ok, Yes, and OK, and then close Internet Explorer.  This of course requires you to have permission to change these settings.

I felt like I was making progress with this error.  Still though, the fix requires admin privileges.  Not a real solution.  I then started trying to figure out why this setting needed to be enabled.  I reopened the 32-bit version of Internet Explorer, and from the Tools menu, selected Manage add-ons.  This opens up the Manage Add-ons dialog.  In here, I chose to Show: All add-ons.  With this option selected, two add-ons published by ESRI show up: MdDatasetCtrl Class and MdStaticTextCtrl Class.  For me, they show up as Not Verified, meaning that Internet Explorer is seeing them as unsigned controls.  Now, I found it really hard to believe that ESRI neglected to sign their controls, so the question was Why are they showing up as unsigned when all of the Add-Ons from other publishers appear as signed?

When I click on each of the controls and ask for More Information, I see that both of these controls are pointing to ArcGISVersion.dll.

Note:  For each of these controls, I chose the Allow on all sites option.  The only effect this seems to have is to show a blank script error dialog box instead of one with an error description.

I then browsed to the location of the ArcGISVersion.dll and opened its properties.

The first thing I noticed is that it is missing a Digital Signatures tab where you can ask to see the digital certificate for the control.  For example, here are the properties for a verified Adobe ActiveX control.

This was curious, so I read about the Digital Signatures tab. I learned that there are two different ways to sign dll's. One way is to use an embedded digital signature. The other way adds a hash of the executable to a security catalog file (.CAT). The embedded digital signature produces a digital signatures tab, and the catalog file does not.

At this point, I am beyond my level of trouble-shooting, and I am left to wonder if Internet Explorer will only verify controls with an embedded digital signature.  Mind you, I am not even 95% confident that this is the problem. I sent an email about this issue to someone I know at ESRI, and I am confident that if anyone will get to the bottom of this, he will.  So stay tuned, and let me know if you have any other thoughts or ideas.

Leslie