Program runs ONLY if debugger is attached

I have an interesting (and incredibly frustrating) problem where my application runs fine, but ONLY when a debugger is attached to it.

I can build in both Debug or Release and double clicking the execuable causes it to crash before the window is drawn. However if I launch from the IDE (VS2010), again in both Debug or Release mode, the application runs perfectly fine.

I'm at a loss and have no idea how to debug in this situation.

All suggestions welcome.

I am using VS2010 in Windows 7, C++ with MFC. This is an application which has been migrated from VC++ 6 to VS2010. Note, it works perfectly when built from VC++ 6.

Thanks,
AnotherMuggle.

A possible cause is that you are running your VS in elevated (UAC) mode, and this is how your app is expecting things. When ran outside of VS, your app runs un-elevated which may be causing the issues.


First thing would be to identify if your app really does need to run elevated.
If it does, then provide a UAC manifest to request elevation.
If it doesn't, then change the code that depends on UAC elevation to no longer require this.


Typically speaking, other than typical "admin mode" type programs and installations, your program should not require UAC elevation.

Did you get any hint at what the problem could be when you pressed Retry in the crash dialog?

Thanks both.

I've finally managed to get to the bottom of the crash but still no idea why it happens only when no debugger is attached.

The problem is caused when loading a particular dll, which I believe was built using VC++ 6, and hense there is a compatability issue between my build and theirs!?

I'm still not sure why having the debugger attached stops the crash though!?

I tried running the application with "Run as admin" which I believe is the same as "UAC Elevated Mode"?

Additionally I added the following early in the source code, which allowed me to run the executable with double-click then attaching a debugger:

Code:

---

while(!IsDebuggerPresent());

---

When doing the above the application still didn't crash.

Weird :confused:

You may have a memory buffer overflow which is affecting the code. Putting in the above line may mask the problem which is still present. Just because it 'worked' in vc6 doesn't mean that there isn't a problem - only that it wasn't seen then.

Quote:

---

Originally Posted by AnotherMuggle

The problem is caused when loading a particular dll, which I believe was built using VC++ 6, and hense there is a compatability issue between my build and theirs!?

---

Did you try to rebuild this DLL with VS2010?

Another possible cause for different behaviour when run by double-clicking it in Explorer vs. running it from inside the IDE is the current working directory. When run from Explorer, that is the directory withe the .exe file in it, while, with default project settings, it's the project directory (the one containing the source files) when run from the IDE. This may, obviously, decide about whether some external file is found or not, or, in case there's two versions of the file, which one gets accessed.

If the above is the cause of the issue, the program should run fine when started from the IDE with "Run without debugging", just like running it in the debugger.

Quote:

---

Originally Posted by AnotherMuggle

The problem is caused when loading a particular dll, which I believe was built using VC++ 6, and hense there is a compatability issue between my build and theirs!?

---

It doesn't matter what tool built the DLL or how old the DLL happens to be. You can run DLL's created 15+ years ago with the latest Visual Studio if the DLL's follow certain guidelines.

If the issue is the load of the DLL, then on the startup of the DLL, it may have bugs in DllMain(). If you're calling a function from the DLL, maybe the parameters do not match up, where they don't match in type or functionality (for example, the DLL takes a std::string argument, and you pass it a std::string created with Visual Studio 2013).

Quote:

---

I'm still not sure why having the debugger attached stops the crash though!?

---

Any program that has memory corruption or overwrite bugs cannot be guaranteed to run reliably in any environment. It is as simple as that. Maybe your program has these issues.

Regards,

Paul McKenzie

Thanks for all the kind responses.

I am fairly confident this is the explanation for my problem: http://siomsystems.com/mixing-visual-studio-versions/

Paul - am think in this case the rules have been broken! Out of interest I tested breaking some of those rules, as detailed in the above link, and sure enough it exhibits very similar symptoms.

Regarding rebuilding the DLL in VS2010, which I am sure will solve the problem, this is possible but I need to arrange a rebuild with the owner of the source.

Thanks again,
AnotherMuggle