Rick Strahl's FoxPro and Web Connection Web Log
White Papers | Products | Message Board | News |

Fixing wwDotnetBridge "Unable to load Clr Instance" Errors


Thursday, October 24, 2013, 5:32:42 AM

In recent weeks a few people have run into the Cannot load CLR Instance error when trying to use the wwDotnetBridge class from Visual FoxPro. The cause for this problem is a security issue in Windows and some new security features in .NET 4.0 when running under User Account Control (UAC) in Windows.

The Problem

wwDotnetBridge is distributed as part of a simple .Zip archive - you download a .zip file and copy the files to your local machine. Unfortunately Windows recognizes that .zip files out of the Downloads folder contain 'downloaded' files and so adds some additional security flags onto files copied to the local machine. These security attributes cause a problem when trying to load the dll.

If you now try the simplest thing possible:

DO wwDotnetBridge
loBridge = CREATEOBJECT("wwDotnetBridge","V4")
? loBridge.GetDotnetVersion()

you'll find that you get an error Unable to load wwDotnetBridge: Unable to load Clr Instance. 0x80131515.

unabletoload

in this code:

*** Fail creation if the object couldn't be created
IF ISNULL(this.Load())
   ERROR "Unable to load wwDotNetBridge: " + this.cErrorMsg
   RETURN .F.
ENDIF

However, if you try to load "V2" of the runtime you'll find that the DLL loads just fine.

Unblocking the DLL

Luckily the solution to this problem is generally quite simple. You simply need to unblock the DLL. To do so:

  • Open Explorer
  • Find wwDotnetBridge.dll
  • Right click and select Properties
  • Click the Unblock button

Here's what the dialog looks like:

UnblockwwDotnetBridge

Distributing your App and avoiding Unblocking

It would really suck if these steps had to be done with a distributed application. But fortunately this problem pops up only if the DLL originated from an Internet Download either as the file directly or as part of a zip that just copied the file to the hard disk. These specific steps of actions effectively mark the DLL as suspicious code which is the cause for the error.

For your final deployed applications however, this shouldn't be an issue. If you install your application using a Windows installer or other process that runs as an Administrative task (ie. permissions were elavated as they are for software installations typically) the DLL file gets properly installed and you will never see this issue pop up.

Unfortunately this is a bummer for development and people trying for the first time to use wwDotnetBridge because the component is shipped as part of a .Zip file that is likely downloaded. So a large chunk of developers are likely to see an issue with this.

Other load Problems

Note while Windows blocking likely is the most common problem, there can be other things that cause problems. Loading from network shares is problematic for example, unless you either provide custom policy settings or a configuration file setting. You can find out more in the helpfile on how to run wwDotnetBridge or any other .NET assemblies from a network location.

Remember me, Remember me, Remember me

I'm hoping that this blog post will make the issue at least a bit easier to search for, since the solution is typically relatively simple.

Here's a funny anecdote about this error: I had run into this problem before, and actually had spent the time to add some documentation in this regard into the help file. In fact, if you look at the wwDotnetBridge topic in the help file - in the remarks on the bottom -  you'll see this issue addressed along with a detailed link to more info. I however had forgotten about the whole issue, so last week I've been going back and forth with two developers who were running into this problem. Not only that but I couldn't duplicate it, because my copy of wwDotnetBridge.dll isn't copied from a downloaded .zip file and I typically run as an Administrator. Only when I looked up the error code and found out the security issue and reference to unblocking did I finally remember that I solved this problem before :-)

So, yes, writing it down again is probably a good idea.

Posted in: Web Connection    FoxPro    wwDotnetBridge    .NET

Feedback for this Weblog Entry


re: Fixing wwDotnetBridge "Unable to load Clr Instance" Errors


Using Windows 7 Ultimate, I see no such security section and "Unblock" on the General tab of the Properties dialog.

Nonetheless seeing the wwDotnetBridge "Unable to load Clr Instance" error.

Any other ideas? Is there a command-line equivalent of this?

re: Fixing wwDotnetBridge "Unable to load Clr Instance" Errors


@Steve - there's no command line option to unblock since this is a security feature that's meant to be done by the user explicitly off internet downloaded content.

There's additional info in the wwDotnetBridge FAQ:
http://www.west-wind.com/webconnection/docs/?page=_3rf12jtma.htm

If you don't have the 'unblock' option that just means the file is not blocked and so your issue is something else.

The other common things are:

* Network loaded assemblies (addressed in the link in the post and docs)
* Non-Full version of .NET (Client Profile is not enough)

re: Fixing wwDotnetBridge "Unable to load Clr Instance" Errors



Ian C.
Hi All.

There now exists a command-line tool to unblock these downloaded files. PowerShell has the Unblock-File commandlet.

See http://ss64.com/ps/unblock-file.html

re: Fixing wwDotnetBridge "Unable to load Clr Instance" Errors



Chris B
Rick-

We are getting a similar "Clr Instance..." error but with a different hash identifier as follows:

Unable to load wwDotNetBridge: Unable to load Clr instance.0x8007000e:

We are using the WW library v.6.15 DtNetBridge DLL with a custom VFP v.09x enterprise platform on our LAN. VFP and the enterprise platform is running on Windows 2012 R12 Server and have .met v4.7 running as well.

The error is odd as it is occasional/intermittent and does not always occur. It just started occurring today.

Any ideas?

Chris

 



© Rick Strahl, West Wind Technologies, 2003 - 2018