Wednesday, June 11, 2014

Dynamics GP crashes after installing AddIn DLL with System.IO.FileLoadException error

By Steve Endow

A client was trying to test some Dynamics GP AddIns on their server, but when they copied the DLL files to the AddIns folder, they could no longer launch GP.  It would crash immediately.

When we clicked on View problem details, it displayed a rather convoluted and generally meaningless pile of technical error information.  Here is an example of the error details:

Faulting application name: Dynamics.exe, version:, time stamp: 0x52784445
Faulting module name: KERNELBASE.dll, version: 6.1.7601.18409, time stamp: 0x53159a86
Exception code: 0xe0434352
Fault offset: 0x0000c42d
Faulting process id: 0x111c
Faulting application start time: 0x01cfacec50a1c5aa
Faulting application path: C:\Program Files (x86)\Microsoft Dynamics\GP2013\Dynamics.exe
Faulting module path: C:\Windows\syswow64\KERNELBASE.dll
Report Id: 91d6dc87-18df-11e4-88f1-001e4f4c0702

Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: dynamics.exe
Problem Signature 02:
Problem Signature 03: 52784445
Problem Signature 04: mscorlib
Problem Signature 05: 4.0.30319.18444
Problem Signature 06: 52717edc
Problem Signature 07: 26fb
Problem Signature 08: 0
Problem Signature 09: System.IO.FileLoadException
OS Version: 6.1.7601.
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

The only thing that seemed recognizable was this detail:

Problem Signature 09:  System.IO.FileLoadException

So presumably GP or the AddIn couldn't load a file.  While a clue, it doesn't narrow things down very much.  Is that due to a missing dependency?  Permission issue?  .NET version issue?  x64 vs. x86 issue?

After some searching, I found a GP forum post where another user had the same problem.  A very astute forum reader pointed me to Patrick Roth's blog post where he describes the general problem, but  he doesn't mention the System.IO.FileLoadException detail.

Patrick explains that he finally tracked the problem to the Windows security feature that automatically blocks certain files when they are downloaded from another source.  I don't know the proper name for this annoying feature, but I call it "Block" / "Unblock".

When an EXE or DLL is downloaded, particularly using a web browser, Windows blocks access to the file until you go unblock it.  In the case of DLLs, it seems the only way to do this is to go into the file Properties and click on Unblock.

This feature is insidious for software developers who have to distribute EXE and DLL files.  When the file is blocked, it is done at such a low level that you have very little information to track down the problem.  And with the growing use of services like OneDrive, DropBox, Box, etc., I speculate that downloaded customizations will run into this issue more frequently.

Anyway, many thanks to Patrick Roth for posting his observations, and for user Mary on the forums who pointed me in the right direction!

Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter

No comments: