Posted by William Diaz on April 8, 2011
Open exiting some client management software program each time, our user ran into the following error: “The instruction at … references memory at …. The memory could not be ‘read’…”
This is a network based application that relies on .Net 1.1 so previous troubleshooting involved removing and reinstalling the .Net dependencies, all to no avail. An important detail was overlooked, though, which would have saved us time and get the issue properly escalated: our user was a timekeeper for another user, who also was running into the same error on their workstation when exiting the application. From this minor detail, we could assume the issue was not workstation or user specific.
Beyond this, I have no insight behind the internal workings of this application. But, that did not mean we cannot turn to the power of the dump to get an idea of what was happening. When you encounter such an error dialog, do not click OK, do not pass go, do not collect $200. Instead dump the crashing process.
After creating a .dmp file, I copied it to my workstation and opened with WinDbg from the Windows Debugging Tools. In the only thread was an important clue in the top frame of the stack (you read threads and stacks going up, so this would be the last routine before crashing):
cmsbase is the module and the “!” tells us where the function starts, in this case CMSTempFile Size. Then user heard me muttering to myself this and noted that the attorney’s Subscription List was rather large. Upon escalation to the software developer, this issue was confirmed as a bug with large subscription lists. To correct, the subscription list needed to be shortened (or recreated in cases where it persisted).