Dynamics GP Crashes After Installing Addin
One thing we've noticed recently is an uptick of cases involving Visual Studio Tools assemblies causing Dynamics GP to crash after being installed.
While I don't think this has anything to do with GP 2013, it does seem to happen on that version. Perhaps everyone is just going to the new version and thus coincidental.
The first case I recall seeing was a developer trying to deploy his customization to the customer site. It worked fine on his machine but as soon as it was installed to the \Addins folder on the customer machine and Dynamics GP was launched - it crashed.
I had him send it to me as well and sure enough, it crashed my install as well.
The usual suspect for this kind of crash is actually references of your application. You app references some type of component that isn't installed. .NET throws an exception of some sort which ends up crashing GP. That isn't terribly unusual.
But then I had him compile the Estimate Freight sample from the VSTools SDK. And that crashed too on both the customers' and my own machine.
Puzzled, I could at least test this on my own system easily.
I tried Windbg and I didn't see anything that looked like It would cause a crash.
The Fusion Log didn't seem to show a problem either.
I tried the old stand-by, Process Monitor and that didn't shown any issue I could tell either. Everything for my EstimateFreight.dll showed OK, no ACCESS_DENIED errors to be found.
Now very much puzzled and a little unhappy that I couldn't solve this - I idly checked the properties of the dll.
Oh, yeah that could be it.
At the bottom of the window, the message reads:
Security: This file came from another computer and might be blocked to help protect this computer.
And it gives an "Unblock" button that normally doesn't show.
Sure enough, pressing the Unblock button makes the error message go away.
Launching Dynamics GP again, I find that it no longer crashes and I can log in normally.
So what happened?
That's a good question and I believe it is more an "OS" thing than a "GP" thing.
To be honest, I didn't research this much further once I found the solution but I would suspect UAC. But I had a few of the other guys test this on their systems on Windows 8 and none of us had adjusted the UAC settings. We found that two machines crashed and one did not. On the one machine that did not, checking the properties of that assembly on the machine didn't show this Security warning. So that explains why it worked - but not why it chose to ignore the fact that it "came from another machine" and just trusted the assembly.
In order to make the assembly untrustworthy, even coming from my own machine, I chose to upload it to my SkyDrive/OneDrive account. Then I downloaded it again. This was what the ISV had used to transfer it to the customers' machine as emailing dlls typically gets filtered out by the email server. And as I discovered, this was the first time he had used this method and so was the first time he ran across the issue.
With this case, whenever I get a new case along the lines of "GP crashes after installing my new vstools assembly" I always check for:
- Check the properties for the Security warning and Unblock it if necessary
- Check the References of the assembly and make sure the required components are loaded on the target machine.
These two tips have solved most if not all of my cases like this.
Best of luck,
Patrick Roth
Senior Escalation Engineer