Juce application dies mysteriously: only in "release", no VS

#1

Hello, Jucey people. I have a Windows-only issue that’s getting me down. Yes, it’s probably off-topic.

I have a crossplatform Mac/Windows application that’s been running well on both platforms. I made a large number of small changes to it, tested it on the Mac and on Windows in Visual Studio 2010, and it seems to work fine.

However, if I run the executable from Windows Explorer, it brings up the main window - and then, nearly all the time, dies (“XXXX has encountered a problem and needs to close”).

I can run it four different ways from inside Visual Studio 2010 - either the Debug or Release build, and either Start Debugging or Start Without Debugging. It works perfectly every time I’ve tried it.

I have some leads on how to start debugging - but how could this be happening? What’s different when I run a release-build application from VS2010 without debugging and then run it on its own?

#2

maybe you are trying to write into a file in the current working directory, which is a non-writable directory when the application is launched from the explorer ? I thing it happened to me once, I had left (and forgot) a debug log file ; fopen(…) returned NULL and the app crashed when started from explorer.

#3

Interesting idea!

I’ll check it out - and even if that isn’t it, it’s such a good piece of information to know, thanks!

#4

You should be able to collect a user mode crashed dump, and analyze it using Debugging Tools for Windows.

If you have the symbol file for the offending application, that should tell you precisely where the problem is happening.

Matt

#5

Try adding this to the Release settings of Project Properties->Configuration Properties->Debugging->Environment

_NO_DEBUG_HEAP=1

Then launch with the debugger attached and see if it dies.

#6

uninitialized values ! (which contain other values when you run it from the ide)
Whenever i had this reason unitnitalued values were the reseon:
or memory/heap-violation

Turn map file generation on - and make a back trace where the problem happens