Microsoft Dynamics GP Technical Conference 2011 - Day minus 2
Sunday started with a late breakfast at the hotel. However, it was straight to work afterwards. We commandeered a table in the Bar area and Mariano and I started working on fine tuning our presentations and demonstrations for the Technical Conference sessions.
What should have been a quick run through of the demo ended up as an entire day of frustration after I had some issues. We are currently experiencing Technical Difficulties and will return to our regular programming as soon as possible.
Those Technical Difficulties ending up wasting about 5-6 hours of the day and had me grumpy and ready to do violence to my machine. Now as this is meant to be a technical blog I suppose I better explain what happened and why it was so hard to resolve. You can read Mariano's version or Leslie's version, or read the truth what really happened below:
Here is the story....
Once upon a time, there was a man who was trying to create a demonstration of a Dexterity customisation, let's call this man, David.
Well, David noticed that a script he was attempting to compile failed because the DYNAMICS constant (value 0) was missing from the development dictionary he was working on. Further investigation showed that there were only 5118 constants in the dictionary when a source code version of the same dictionary (GP 2010 SP1) had 7284. While it was possible to add the constants back by extracting them from the source code dictionary and importing them, this would probably cause issues as the resource IDs might change and there was no telling what other corruption there might be to the dictionary.
So, the first and simplest solution would be to re-install the Microsoft Dynamics GP 2010 client and get new DYNAMICS.DIC to use as a development dictionary. Simple, just un-install the current install and install again. Except that any action to Remove, Repair or Add/Change the current installation resulted in the following error message:
"Object reference not set to an instance of an object"
So David thought ... my current GP installation works fine (except for the dictionary seeming to be missing constants), why not install another instance of Microsoft Dynamics GP 2010 to just grab a clean DYNAMICS.Dic dictionary. So he went back to his room and grabbed his external hard drive, only to find that it did not have the GP 2010 install files on it. Luckily his friend, Mariano, had the Microsoft Dynamics GP 2010 SP1 install files on his machine and was able to copy them to the external hard drive.
After installing a new instance of the Microosft Dynamics GP 2010 client on his machine, David confirmed that the dictionary was exactly the same with the missing resources. It looks like the dictionary is damaged when selecting Australia as the country. This issue will need some further research at a later time. So the new instance was no help and it un-installed with no issues.
David was able to find a Dynamics GP 2010 RTM DYNAMICS.DIC which he then used to complete the Dexterity customisation example he was working on. Next, he had to work on a Modifier and VBA example. Opening up Dynamics GP and attempting to load some code via packages caused GP to hang. It looks like installing and un-installing the other instance had damaged the VBA functionality as it was completely failing. Look at the photo below and you can see the Customisation Maintenance window in its hung state.
David and Mariano - David only smiling because Leslie made a joke as she took the photo.
Now, David REALLY DID need to re-install his Microsoft Dynamics GP 2010 installation to get VBA working again. So back to trying to solve the error message:
"Object reference not set to an instance of an object"
Doing some research on the internal helpdesk search engine, David found that the only solution seemed to be to forcefully remove Microsoft Dynamics GP 2010 from Control Panel >> Programs and Features (Add/Remove Programs) using a tool called the Windows Install Clean Up utility. This utility is no longer available or supported, but can be found if you look for it (it is attached to the bottom of this post). After installing the tool, it was simple to remove Microsoft Dynamics GP 2010 from the installed applications list.
So, now it was possible to run the Microsoft Dynamics GP 2010 installation again and not get the Object Reference error. The re-installation looked like everything was going to work until the system reported a new error message:
"Could not open key:
UNKNOWN\Components\XXXXXXX\2A8725E6854A7684B9F00100FA6CA510. Verify that you have sufficient access to that key, or contact your support personel."
So, after following the definition of stupidity a few times (ie. trying the install a few more times to see if the error went away or changed.... it didn't), David tried to locate the keys in the registry that the error was referring to. The problem was that the key described in the error message is not complete and the numbers given did occur in more than one location. So Mariano reminded David about using the Sysinternals Process Monitor to capture the registry error and locate the full path. After scanning the Process Monitor for the number, the full path was identified as
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\2A8725E6854A7684B9F00100FA6CA510\2BE9545F266A3BE4DA497E17CDF245A2
Looking at the permissions, on the keys, they appeared to be fine, but accessing the key on the tree would generate a permissions error. Attempting to edit the permissions also generated an error.
Just about then another friend, called Dave, turned up and suggested turning off UAC (User Access Control). So, UAC was disabled and the machine rebooted, but this made no difference. The next idea was to log in as the machine's local administrator, but that also made no difference.
Finally, the "team" thought about forcefully taking ownership of the key and its sub keys. Using Edit >> Permissions >> Advanced >> Owner Tab and changing the Owner to the local administrator and rolling the changes down, then allowed the permissions to be edited. Now permissions for the the local administrator user could added to the keys.
Re-running the install, got past the registry error, only to complain again on a different key. The taking ownership process was repeated again and the installation was able to proceed further. However, it came across yet another key that had bad permissions. Instead of continuing fixing individual keys one at a time, it was decided to move a level up in the tree and apply the fix at that level.
After 5-6 hours of shouting, swearing and general unhappiness, the Microsoft Dynamics GP 2010 SP1 install was able to complete.
It was then Dave said "And there was much rejoicing throughout the land.".
A short time later the VBA demonstration was completed.
And they all lived happily after.
After a such a stressful day, it was time to shutdown the computer and chill out.
We were going "stir crazy" in the hotel, so it was decided to brave the outside world and walk to Granite City (over the road from the hotel).
David, David (Dave), Leslie and Mariano - All rugged up ready to leave Granite City after dinner.
After a long day, it was good to be back to my room and get some sleep, hopefully tomorrow will be better.
David
03-Mar-2011: It turns out that the missing constants issue affects all countries other than the US. This is because when the XXERR.CNK language chunk is applied for GP 2010 SP1, it is somehow damaging the DYNAMICS.DIC and blowing away some 2000 constants. This issue should be fixed soon, in the meantime it is possible to use the RTM Dynamics.dic to develop with and use the DEX.INI setting SkipVersionChecks=TRUE.