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:
These two tips have solved most if not all of my cases like this.
Best of luck,
Patrick RothSenior Escalation Engineer
I have found that IF the add-in is emailed or downloaded, in some instances the OS blocks the DLL, but on 2 occasions, I have seen that the “Unblock” button won’t work, without a long explanation, you will need to copy the DLL to a flash drive or other location, unblock it there and bring it back to the AddIns folder.
Good tip but a bit puzzling. The only thing I can think of it is maybe due to not having permisions to the \Addins folder if you have UAC enabled and GP installed to the default Program Files folder.
I've also run into this issue and the Unblock didn't work (you could press the Unblock button and it appeared to work but would show blocked again after reopening the Properties window). Zipping the file up, deleting the original, and then unzipping it again removed the block.
Thank you so much for posting this. I was getting GP crashes on startup with a System.IO.FileLoadException message with some addins and it didn't occur to me to check the file blocking property on the DLLs.
The issue did not occur when I copied the DLLs between my development servers, but it does occur if I download a zip file from OneDrive.
Any time files come over the internet, the security block is activated. OneDrive is an internet based service.
This article saved me countless hours. Thank goodness for the Internet!
Glad that this article helped.
PLEASE READ BEFORE POSTING
Please only post comments relating to the topic of this page.
If you wish to ask a technical question, please use the links in the links section (scroll down, on right hand side) to ask on the Newsgroups or Forums. If you ask on the Newsgroups or Forums, others in the community can respond and the answers are available for everyone in the future.