Take the 2-minute tour ×

A colleague of mine created an assembly in VB.net for use with JScript via COM interop. The assembly used to work fine, but we signed it and now it only seems to work on Windows 7 machines. I've tested 2 Windows 7 machines and 2 Windows Vista machines.

When we signed the assembly and we try to instantiate the ActiveX object in JScript, an error is returned with no message and only a number:

Error number: -2146234304

A search on Google for the error number didn't return much.

If we remove the strong name from the assembly, it works just fine. Any ideas on what could be the problem? Not sure if it makes a difference, but the assembly is being compiled and signed with VS 2010.

share|improve this question
In your case, I think -2146234304 is S_FALSE or ERROR_INVALID_FUNCTION. err.exe is useful for looking these error codes up, see blogs.msdn.com/b/astebner/archive/2008/06/17/8611734.aspx –  Chris Schmich Sep 19 '10 at 22:03
add comment

8 Answers

up vote 6 down vote accepted

Do you recreated the COM Interop after the signing of the assembly? How you register the new version of the assembly? Do you cleared the cache of Internet Explorer?

In general the error -2146234304 (0x80131040) means FUSION_E_REF_DEF_MISMATCH: "The located assembly's manifest definition with name [yourAssembly] does not match the assembly reference". So you have to update the manifest of assembly which use your signed assembly. What it means exactly in your situation you should find out. The refence to the assembly are saved also under Assembly value of HKEY_CLASSES_ROOT\CLSID\{YOUR_GUID}\InprocServer32 and not only in the real manifest.

You can try to investigate the problem with respect of Fuslogvw.exe (Assembly Binding Log Viewer) (or http://msdn.microsoft.com/en-US/library/ms229864(v=VS.80).aspx). Some changes in registry under HKLM\Software\Microsoft\Fusion could be needed before (like EnableLog, LogFailures,

If you will not solve the problem in the way you could post a link to a project which could be used to reproduce your problem.

share|improve this answer
regasm.exe was how I was registering it. In the final version, the script needs to register the control by writing the registry keys, so it mimics the output from regasm.exe. I can do this on Win 7 with no problems but I can't instantiate the signed assembly on Vista. Thanks for your advice, I'll check it out and let you know how it goes. –  Andy E Sep 20 '10 at 6:55
@Andy E: One more remark. If you not yet made your Assembly "Safe For Scripting" I recommend you to do it. It's very easy. You have to implement IObjectSafety interface (see blog.devstone.com/aaron/archive/2007/06/12/2409.aspx and atalasoft.com/cs/blogs/rickm/archive/2009/06/03/… for example) –  Oleg Sep 21 '10 at 0:05
@Andy E: Do you have any progress in your investigations? Do you tried to reset Zone security settings and IE cache inclusive "C:\Windows\Downloaded Program Files" of all IE settings on the Vista computer which has problem? Could you describe more how you sign the assembly? Including Key in the Visual Studio project, including in AssemblyInfo.cs, or you use Delay Signing with respect of sn.exe of SignTool.exe? Do you use pvk file of a code signing certificate? If you use certificate, is it from well-known authority or self-signed? How you deploy the assembly to the destination computer? –  Oleg Sep 22 '10 at 8:55
@Oleg: thanks, it looks like it might be more or less sorted. Your answer helped, but it seemed like the solution was to generate a new public key token. I've tested it and it's working on one machine, I just need to test the others now. –  Andy E Sep 25 '10 at 19:25
@Andy E: It would be nice if the solution is so simple. :-) It you do will have some problem let me know. I find all question concerned code signing interesting. I will try to help you independent on any bounty. –  Oleg Sep 25 '10 at 19:35
show 1 more comment

The error code ix 0x80131040. That's a code that matches a .NET exception, a very common one.

The located assembly's manifest definition does not match the assembly reference.

I'm surprised you don't get a message for it, you might want to review your error handling code. Anyhoo, you've got a bit of DLL Hell going on, the CLR is finding an assembly whose [AssemblyVersion] or PublicKeyToken doesn't match the reference assembly that was used to build the code. Given that this is associated with a strong named assembly, you might have signed the assembly after building the code. In which case simply removing the assembly reference from your project and adding it back, now selecting the strong named assembly, will fix the problem.

But no need to guess at this, the Fuslogvw.exe utility will tell you exactly what is going wrong. Run it first to get a trace of the binding attempt and the reason it failed.

share|improve this answer
Thanks, Hans. Generating a new public token looks like it may have solved the problem, I just need to perform more testing. –  Andy E Sep 25 '10 at 19:26
add comment

Use dependency walker to open your signed dll on the problematic machine. It should tell you why the dll can't be loaded. It could be dependent on a dll which is different between windows versions, which is more a problem after signing.

share|improve this answer
Thanks, I'll check it out. –  Andy E Sep 20 '10 at 6:58
add comment

Andy, not sure if this is relevant. The solution there says:

I forgot to update the adxloader.dll (from the new one in \Add-in Express .NET\Redistributables) in the path - I guess it's been updated...

share|improve this answer
Hi Peter. Thanks for the link, but I'm not using Add-in Express. I have a feeling the problem might be related because I think Add-in Express works in a similar way to our own assembly (heavily relying on System.Reflection). –  Andy E Sep 20 '10 at 6:57
@Andy: No worries! I thought it sounded similar. Sorry it wasn't more help. –  Peter K. Sep 21 '10 at 0:32
add comment

your number looks very much like the beginning of the integer range!

Signed: −2,147,483,648 to +2,147,483,647, -(2^31)~(2^31-1)

maybe you have a casting error, or a really huge number you're trying to increment and if it reaches the maximum (+2,147,483,647) it starts counting backwards from −2,147,483,648

Just a guess!

share|improve this answer
add comment

Are you using the Microsoft Enterprise Library code blocks at all? I have seen this issue pop up with folks not adding a reference to the correct signed libraries when they compile their code.

Here's some more background if you are using EnterpriseLibrary.

share|improve this answer
add comment

Try signing your assembly from a working XP configuration (or from the Vista box). CAPICOM is not supported in Windows 7 so whatever the sign tool may be doing to sign your assembly may not be backwards compatible with Vista. Now I have seen CAPICOM work just fine, but I have also seen it fail for no reason, and "unsupported" means that's what you get from Microsoft support if you try to call.

share|improve this answer
add comment

Go to the .Net Framework Configuration console and play with the Runtime Security Policy settings on your machine.

share|improve this answer
add comment

Your Answer


