A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
Talk about taking an old problem and confusing it; I have a VS.NET application (written in C# and containing wrappers to unmanaged C functions) which is working fine in release mode, but when compiled in debug mode (and the binary is executed, NOT running through the VS.NET debugger) attempting to close the application results in strange and (to me at least) inexplicable decision paths being taken.
Has anyone had any experience with this sort of problem in the past?
Tuesday, March 21, 2006
Have you checked the variable values in the debugger?
In Release mode, variables that are not initialized have no defined state. However, in debug, memory is set to predefined values, allowing you to spot an uninitialized pointer in C with the value of 0xCDCDCDCDCD for example, or a previously freed memory with something like 0xfrefrefre. This is the case for C and C++, but not sure about C#.
Perhaps this change from a completely random value is causing your program to deviate from the way it does in release mode?
I've found this article to be useful. Although it refers to release mode problems, it's also good for debug mode issues as well.
I would definitly check out the variables in the debugger. My suspicion is that some memory is getting whacked somewhere or isn't initialized properly in the first place. I've had similar issues where the debugger initialized everything *just right* and it worked, while running outside of the debugger caused a crash.
The debug vs. release issues with uninitialized variables is true for native C/C++, but is not true of .NET. In .NET variables are always inititalzed to 0 (or empty string or whatever) for you so that is not an issue AFAIK. I would imagine that the problem is in the unmanaged code.
Friday, March 24, 2006
So what's the status of this problem? If it's still unsolved you might want to take a look at this recent MSDN article by Stephen Toub:
It's about "managed debugging assistants" in Visual Studio 2005 which are used for automatic tracing & breaking on common problem sources. A bunch of them relate to native code interoperation which I'm pretty sure is at the heart of your problem.
Saturday, April 01, 2006
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz