Several weeks ago, an ISV posted to the forums that he had thrown caution to the window and upgraded his Dexterity DSCCS 7.5 to DSCCS 2010. The install went OK for him (unlike my own install that I discussed in a previous post) but what he found was that he wasn’t able to check in resources with Dexterity using this version.
David Musgrave had previously mentioned this issue had come up for him as well.
Having my fresh install to test with, I attempted to check in a couple different Dynamics customizations as well as the RESM sample dictionary into VSS. No troubles at all – so I wondered if this was an environmental issue of some sort?
As it turns out, this was one of those times when “exact repro steps” would have been useful.
After a couple more successful attempts at checking in new single and multiple items, I thought perhaps I’d try checking in multiple checked out resources. That was it- Dexterity crashed on me.
After a bit more testing, here is what I found.
When attempting to check in a single checked out resource, the DSCCS.exe service is stopped and the check in fails.
If you attempt to check in multiple resources (I tried 3), Dexterity crashes. I believe the reason is that after the first resource fails and stops DSCCS, the next call to DSCCS isn’t handled causing Dexterity to crash.
Using Windbg, I was able to capture a stack dump of DSCCS failing when checking in an existing resource.
Looking at the dump file captured, it indicated that there was a memory overwrite occurring which is usually caused by a string being longer than the allocated variable size. To see where that might be occurring, I set up Dexterity and restarted DSCCS. I then checked in my resource and walked through the C source code of DSCCS to see if I could find out why this was occurring.
After running through this several times, I still couldn’t see where the overwrite was happening. The debugger said it was happening (and threw an unhandled exception) but I sure didn’t see it.
Not getting too far with that approach, I made one last check in Windbg and ran the command “!analyze -v” to see what Windbg said was the cause.
Once more the analysis told me that there was a memory overwrite occurring, but it next told me that this error seemed to be a “false positive”. Interesting – never heard of that before.
At this point, I handed it off for development to look at since it was easily reproducible (and weird).
Happily development did confirm my findings, the false positive reading, and why I couldn’t find the memory overwrite. Apparently between Dexterity 2010 Beta and RTM, a new compiler option flag was introduced when building DSCCS that does more error checking/validation. In this case, the error checking is apparently a little too aggressive and giving an error when when none actually occurred. So that is why the initial “overwrite” was thrown but why the false positive was given when analyzing the crash dump.
So the net result of this is that you won’t be able to use Dexterity DSCCS 2010 RTM that you will find on the GP 2010 image. This has been written up as a bug and will be fixed in SP1.
In the meantime, you can use any version of DSCCS that you have handy. In my case, I just installed the 10.0 SP4 version. David had already went back to the Dexterity 2010 Beta edition of DSCCS. And the ISV? He reinstalled his 7.5 version and went back to work.
Dynamics GP Developer Support