32-bit compiler

[Robert_C_2]

Has anyone had a problem using the 32-bit Fortran compiler after returning from sleep or hibernation mode?  I get an internal compiler error C0000005.

[FortranFan]

Not me - I use the hibernation and sleep mode all the time on a laptop and never had such a problem.

[Steven_L_Intel1]

In all the years I have used the compiler after hibernate or sleep, I've never seen this happen. Is it consistent for you? On any source? If you compile again do you still get the error? I assume the same source compiled ok at some point...

[jimdempseyatthecove]

Are your compilations taking so long you go into sleep and/or hibernation mode?

Jim Dempsey

[Robert_C_2]

Steve Lionel (Intel) wrote:

In all the years I have used the compiler after hibernate or sleep, I've never seen this happen. Is it consistent for you? On any source? If you compile again do you still get the error? I assume the same source compiled ok at some point...

Please note that this is only occurring with the 32-bit compiler, not the 64-bit.  I have no doubt it is system dependent.  It happens on my desktop, but not on my laptop.

Once the computer returns from sleep, the same source that previously compiled properly will not compile.  I get an internal compiler error.  This is true regardless of the source. No matter how many times I attempt to recompile, I get the same error.  The only thing I can do to get the compiler to work again is to restart the computer.

I have heard that an environment variable or a path can be lost after sleep or hibernation.  I assume that something like that is occurring.

[Robert_C_2]

jimdempseyatthecove wrote:

Are your compilations taking so long you go into sleep and/or hibernation mode?

Jim Dempsey

No, the compilations take less than a minute.  I want to take advantage of the power saving provided by sleep/hibernation when the computer is not in use, but I don't want to shut down and wait for the computer to reboot.

[Steven_L_Intel1]

If an environment variable change could cause an internal compiler error, that would be a compiler bug. I'd suggest uninstalling and reinstalling the compiler - get the latest one available - and see if the problem persists.

[Robert_C_2]

Steve Lionel (Intel) wrote:

If an environment variable change could cause an internal compiler error, that would be a compiler bug. I'd suggest uninstalling and reinstalling the compiler - get the latest one available - and see if the problem persists.

I have tested the latest version of the Fortran compiler (and the new Beta version).  The problem persists.

[jimdempseyatthecove]

I've never experienced our symptoms on any of my notebooks over the last 10 years.

Is there anything else we need to know about your setup?

Is the compiler, and licenses server if applicable, located on the notebook? (as opposed to through network or external storage)
Is the compiler running inside a Virtual PC?
other...?

What is your build environment (Visual Studio, the "light" Visual Studio, Eclipse, other, command line)?
If VS, what happens if you have a second instance running a solution for a C++ project (does that error out too)?

Jim Dempsey

[Robert_C_2]

jimdempseyatthecove wrote:

I've never experienced our symptoms on any of my notebooks over the last 10 years.

Is there anything else we need to know about your setup?

Is the compiler, and licenses server if applicable, located on the notebook? (as opposed to through network or external storage)

Is the compiler running inside a Virtual PC?

other...?

What is your build environment (Visual Studio, the "light" Visual Studio, Eclipse, other, command line)?

If VS, what happens if you have a second instance running a solution for a C++ project (does that error out too)?

Jim Dempsey

Please note that the problem is on a desktop, not a notebook.

The compiler and license is located on the desktop.

The compiler is not running inside a virtual PC.

There is nothing else unusual about my setup.

I build the executable on the command line.

I have only the Fortran compiler, and I don't use C++.

[jimdempseyatthecove]

What happens if on resume, you close any CMD window, then open a new IVF command line window?

Error or no error?

Usually when you receive a C00000005 error you have a from ... location. What is the location?

Also, is there any other text shown in the CMD window?

Jim Dempsey

[JVanB]

If this is happening at the command line and you suspect environmental variables, why don't you compare the output of the DOS SET command before and after the problem occurs and see if there are any notable differences?

[Robert_C_2]

jimdempseyatthecove wrote:

What happens if on resume, you close any CMD window, then open a new IVF command line window?

Error or no error?

Usually when you receive a C00000005 error you have a from ... location. What is the location?

Also, is there any other text shown in the CMD window?

Jim Dempsey

Closing the old command window and opening a new command window makes no difference.

There is no location specified.

The only other text refers to "code 1".

[Robert_C_2]

Repeat Offender wrote:

If this is happening at the command line and you suspect environmental variables, why don't you compare the output of the DOS SET command before and after the problem occurs and see if there are any notable differences?

I did what you said, and there are absolutely no differences in the output of the SET command before and after sleep/hibernation. Yet the problem still occurs.

Are there any similar commands I can use to check if there are any differences in my system?

[Steven_L_Intel1]

Try temporarily disabling your antivirus/antimalware program (assuming you have one), then see if you can reproduce the problem.

[Robert_C_2]

Steve Lionel (Intel) wrote:

Try temporarily disabling your antivirus/antimalware program (assuming you have one), then see if you can reproduce the problem.

I only have the software that comes with Windows.  I tried disabling Windows Firewall, but it doesn't make any difference.

[DavidWhite]

Is it a hardware error - a memory fault, for example, so that when windows is reloaded after the hibernation, something has been corrupted, could be in the compiler, or any of the DLL's reloaded into memory.

It woudl be interesting to know whether the error persisted upon exchanging the memory sticks with another set, or even swapping the pair of sticks around (assuming there are two).

David

[Steven_L_Intel1]

There's really no good way to know what the problem is unless it can be generally reproduced. I've never heard of a problem of this nature before and can't imagine what, other than a problem with the particular system, that would cause such behavior.  If restarting the computer is the only thing that solves it, and you tried the latest compiler, my guess is that Windows is failing to resume correctly and has loaded something incorrectly into memory that the compiler uses.

[jimdempseyatthecove]

After resume, then after error (try compile and produce error message)

Snapshot the dialog box (with it in focus, press Alt-PrtScr, then paste into Paint, and save .jpg), and post it here.

Then run MS Event Viewer, expand Windows Logs, see if anything in any of the logs can be associated with the compilation.

Jim Dempsey

[Bernard]

This is access violation error and if Win exception handling mechanism was able to catch that exception you should see a description in Event viewer which could give some information at least the name of the faulting module.I suppose that upon resuming from the sleep state some module (dll?) is mapped back and somehow causes 0xc0000005 error.

[Robert_C_2]

jimdempseyatthecove wrote:

After resume, then after error (try compile and produce error message)

Snapshot the dialog box (with it in focus, press Alt-PrtScr, then paste into Paint, and save .jpg), and post it here.

Then run MS Event Viewer, expand Windows Logs, see if anything in any of the logs can be associated with the compilation.

Jim Dempsey

I have attached the 32-bit compiler error message after resume.  For comparison, I have attached the successful 64-bit compile of the same source after resume.

I found nothing in the logs of the Event viewer that seems associated with the compilation.