Crashes in VISTA 64 bit

[dajum]

Hi,

Can anyone explain why when my application is running under VISTA Ultimate 64 operating system why when it crashes I get the following message:

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

I have set /traceback in the compilation options. (also /fpe:0 if that matters). Is there some reason that I don't get the traceback? I would really like to know where it is crashing without have to add write statements to narrow it down. I can't run a debug version because it doesn't crash (and I beleive just because the numerics take it down a slightly different path, and not just some memory overwrite or other problem).

Thanks,

Dave

[Steven_L_Intel1]

I have seen this message with non-Fortran applications - it is put out by the Visual C++ run-time library. That you are seeing this suggests data corruption in the application. This can be a hard problem to find - I usually start by inserting print statements in various points of the program so I can see how far it gets.

[dajum]

Steve,

But my point was that I want the traceback to work. This only seems to be an issue on VISTA 64, or course it is also the only place I'm using 10.1.024. And Ihave all the optimizations on as well. In this case I know where it is crashing. Right in the middle of fortran routines, but the effort to find this is huge. The tracebacks turns hours of searching down to minutes. In this case it turns out an old routine needed the /Qsave attribute in the flags to avoid the issue. But I get crashes from lots of our users all the time. I can't afford the hours it takes to track them down. Why is it that traceback isn't working. Is it 10.1.024 or is it VISTA? I've never had this problem with 9.0 or 9.1. I have other crashes that I haven't tracked down yet because they are so tedious.

We have always had a mixed language executable. But never problems with tracebacks.

Dave

[Steven_L_Intel1]

I have not seen a general problem with traceback "not working", on Vista 64 or other platforms. If you have a test case we can look at we'd be interested in seeing it.

[jimdempseyatthecove]

Dave,

>>This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.<<

I have incurred this problem too. Not in the application but in the development environment (DEVENV).

Often, exiting Visual Studio and re-launching Visual Studio does the trick.

Rebuild all is the next hack to get the application going.

If that fails, the following hack will get you by until the problem mysteriously goes away

From the IDE in debug mode, instead of setting your normal break point and issuing F5 (run) perform a Step Into(F11). This will get you to the first statement in the execuitable _prior_ to calling the C runtime system. You may get a pop-up stating No Source Code available. If you get this click on Show Dissassembly.

00585170 push ebp 
00585171 mov ebp,esp 
00585173 call __security_init_cookie (595A10h) 
00585178 call __tmainCRTStartup (585180h) 
0058517D pop ebp 
0058517E ret 

Step over the cookie, step into Startup

The above is from a Win-32 window, Win-64 may be a bit different but will functionally be the same.

When you get into the __tmainCRTStartup scroll down about 2 or 3 pages and you will find a call to _tmain or _tWinMain

put a break point on that and press F5.

Now press F5 again and you should get into your application at the intended break point.

I discovered this work around (hack) a couple years back. Why it works I do not know. I surmise there is a race condition with an open file between the IDE devenv and the debug session devenv. The dinking around in the CRT Startup introduces a dwell time that somehow gets you going. Note, the problem goes away as mysteriously as it appeared.

Jim Dempsey

[jimdempseyatthecove]

Dave,

I know the prior suggestion was for use with your Debug session and not the Release session.

You can perform the above suggestion on a release version of your applicaiton. The F5 after the break at the call to _tmain should simply run your applicion (after the dwell in the startup).

Jim Dempsey

[uldry__pierre]

I am interested in this because I am also having some issues with Vista. So could it be that the reason you cannot debug is because the error is not in your code?

And therefore my hypothesis would be that you are compiling with, for example, intel64libraries but then when you run the program somehow the library used is the 32bit version? Or maybe the reverse... Therefore the program starts but then crashes.

Anyway, is that possible?

I would think that in order to test it, all you would need to do isto start the visual studio in IA-32 by goingto programs> Intel...> Intel compiler> Fortran...on IA-32> then "devenv" on the promptand recompile the program to test whether that way it then uses the ia32 libraries. Or the reverse I guess.