Les,
I had spend a considerable amount of time discussing and diagnosingthis issue with MS to no avail. It is one of those things where the problem only shows itself at the customer site. Although I find it hard to believe that with the number of programmers at MS that this problem has not been reported internally.
What I was able to determine, and deductions made therefrom, but unable to convey to MS is:
When in edit session (including Build) your development environment is presented (managed) by one instances of Devenv.
When you launch the app for debugging, the edit instance of Devenv packs its state up and stows it someway/somewhere and then launches a new instance of Devenv for the purpose of debugging the application. You may notice something analogous to a screen blanking of the VS display windows. It is expected that the vertical alignment of the displayed windows to change due to adding in the Watch, Call Stack, whatever at the bottom, but horizontal distributions of the windows and panes are expected to remain the same but are not. Some other clues are apparent (which escape me now).
Additional investigation determined that Devenv was getting a "Memory Access" error, at or near 0x000000005.
My assumption is that there appears to be some sort of race condition on the cleanup of the exit/save stateof the edit session of Devenv with the launch/restore approximate state of the Debug session of Devenv.
The deduction is there are two likely candidates that deserve scrutiny:
1) The operating system is performing some sort of lazy close/delete which is interfering with the restore state for the debugger.
2) This is in combination with (further assumption) an incomplete attempt at producing a multi-threaded Devenv whereby the restore state is assumed to have completed by one thread (e.g. opening up a memory mapped file, or read a buffer, initialized data structures, etc...) and where a different threadresponsible for the debugging resumes/starts prior to the retry or error report by the thread attempting to perform the preparation, and the execution/debug control thread getstripped up executing code under the assumption that some initialization has completed. The "Memory Access error" occurs first or is reported first. Thus hiding the file open/create or the fact that the initialization thread is in a busy retry loop.
The actual problem is likely more complex (subtle) than hypothesized above and potentially good fodder for the likes of Niel Stephenson (Cryptonomicon).
I've also found that when the problem occures, if you close the solution, exit VS, launch VS, open solution, F5 you get going again. So there is something non-obvious going on behind the scenes so to speak. "Don't pay attention to that man behind the curtain" said the man behind the curtain to Dorothy. My gut feel is that some attention is required.
Jim Dempsey
