Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29255 Discussions

0xC0000005 Access Violation Writing Location Error

emreka82
Beginner
27,774 Views

Hi,

I am writing a code with large arrays. The code works fine for small matrices but when I go beyond a certain level, the following error pops out:

Unhandled exception at 0x77913560 in 3d.exe: 0xC0000005: Access violation writing location 0x0000000000050e14.

I am dynamically allocating memory with variables, then deallocating them. The code is very long, longer than 20,000 lines. I want to trace the problem. Before deciding to start this topic, I search the forum and other sources. The "Stack Size" problem has seemed reasonable. I changed reserve size to 200,000,000 and commit size 20,000,000. The problem stayed the same with small differences:

Unhandled exception at 0x77913560 in 3d.exe: 0xC0000005: Access violation writing location 0x00000000001e0e84.

As you can see the code given at the end of the error line is different, I want to know and trace the error. Any kind of help will be appreciated. Thanks !

Emre

0 Kudos
93 Replies
TimP
Honored Contributor III
3,534 Views

If you have VS2008 or earlier, you must specifically add the X64 components in the installation menu under C++, then apply service packs and re-install Intel64 compilers.

0 Kudos
Bernard
Valued Contributor I
3,534 Views

emreka82 wrote:

Quote:

iliyapolakwrote:

@emreka82

Why do not you try to use windbg and application verifier in order to automate the error finding task.

I will give a try, it is on my list. Before installing these kind of  programs, I applied the effects of change in Visual Studio, Virtual Memory etc. Once I am done with these changes, I will install both windbg and application verifier. Thanks iliya.

Good decision.

0 Kudos
emreka82
Beginner
3,534 Views

Sergey Kostrov wrote:

>>...I cannot change the target machine. It has "MachineX86 (/MACHINE:IX86)" or "not Set" selections. I have 64bit Windows operating
>>system...

It looks like a Root Cause of your problems because MachineX86 (/MACHINE:IX86) is a setting for 32-bit platforms and 32-bit applications can not allocate more then 2GB of memory.

>>...Why can't it change?..

Please ptovide exact details for a Visual Studio you use.

I use VS 2010 version 10.0.40219.1 SP1Rel

0 Kudos
SergeyKostrov
Valued Contributor II
3,534 Views
Emreka82, Could you create and attach a simple Fortran project for a review? It is really Not clear why you could not change the Target Machine. Thanks in advance. Please take into account that with a 64-bit application maximum amount of memory a 64-bit application can allocate is more than 1TB ( of course a system must have it installed ). So, there should not be any limitations for Stack/Heap Commit and Stack/Heap Reserved values if the Target Platform is 64-bit.
0 Kudos
emreka82
Beginner
3,534 Views

Sergey Kostrov wrote:

Emreka82,

Could you create and attach a simple Fortran project for a review? It is really Not clear why you could not change the Target Machine. Thanks in advance.

Please take into account that with a 64-bit application maximum amount of memory a 64-bit application can allocate is more than 1TB ( of course a system must have it installed ). So, there should not be any limitations for Stack/Heap Commit and Stack/Heap Reserved values if the Target Platform is 64-bit.

Yes, I open a simple Fahr_to-Celc project implied from Fortran90 textbook and under linker advanced options multiple machine types (MachineX64, SH4, X86 etc)

0 Kudos
SergeyKostrov
Valued Contributor II
3,534 Views
>>Yes, I open a simple Fahr_to-Celc project implied from Fortran90 textbook and under linker advanced options >>multiple machine types (MachineX64, SH4, X86 etc) Did you remove Read Only attribute for project files after you've copied the project to a hard drive?
0 Kudos
emreka82
Beginner
3,534 Views

Sergey Kostrov wrote:

>>Yes, I open a simple Fahr_to-Celc project implied from Fortran90 textbook and under linker advanced options
>>multiple machine types (MachineX64, SH4, X86 etc)

Did you remove Read Only attribute for project files after you've copied the project to a hard drive?

I don't remove but all of the f90 files and other project files are NOT read only as default. By the way, all the files and the program are in D harddisk part not in C harddisk part. Does it make a difference ?

0 Kudos
emreka82
Beginner
3,534 Views

Sergey Kostrov wrote:

>>Yes, I open a simple Fahr_to-Celc project implied from Fortran90 textbook and under linker advanced options
>>multiple machine types (MachineX64, SH4, X86 etc)

Did you remove Read Only attribute for project files after you've copied the project to a hard drive?

I think I found the problem, If you agree then I should reinstall the program. The program that I use is x86. The destination to VS developer is "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe"

Under x64 part of my program files ("C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\") destination there are only vsdiag_regwcf.exe file with PrivateAssemblies and Xml folders...

0 Kudos
SergeyKostrov
Valued Contributor II
3,534 Views
>>...all the files and the program are in D harddisk part not in C harddisk part. Does it make a difference? No, it should not. Please verify how much free space you have on the drive D. >>...I think I found the problem, If you agree then I should reinstall the program. The program that I use is x86... In that case Visual Studio installer ( for example Repair option ) should tell you exactly if 64-bit builts are supported in your current (!) environment. Also, try to use MS Depends utility ( it is very simple ) to verify that your current executables are 32-bit. After 64-bit support in Visual Studio is installed Re-Build the sources and check the executable with MS Depends again and it should show small 64 numbers if the module is for a 64-bit platform.
0 Kudos
emreka82
Beginner
3,534 Views

Sergey Kostrov wrote:

>>....Also, try to use MS Depends utility ( it is very simple ) to verify that your current executables are 32-bit. After 64-bit support in Visual Studio is installed Re-Build the sources and check the executable with MS Depends again and it should show small 64 numbers if the module is for a 64-bit platform.

I use dependency walker. I open "....3d\x64\Debug\3d\3d.exe file.  It gives only "Could not find the section that own the Import directory" warning.

0 Kudos
SergeyKostrov
Valued Contributor II
3,534 Views
>>...I use dependency walker. I open "....3d\x64\Debug\3d\3d.exe file. It gives only "Could not find the section that own the Import >>directory" warning... Could you post a screenshot? Unfortunately, I don't have a Crystal Ball and I can not see what is going on with MS Depends or your computer. Here are a couple of notes: - For a 64-bit Fortran application a linker option Target Machine has to be set as Not Set - Attached is a test project ( a simple matrix multiplication ) and please take a look Note: I use the test project to test my system and more than 128GB of memory successfully allocated when two 64Kx64K matricies multiplied
0 Kudos
Bernard
Valued Contributor I
3,534 Views

emreka82 wrote:

Quote:

Sergey Kostrovwrote:

>>....Also, try to use MS Depends utility ( it is very simple ) to verify that your current executables are 32-bit. After 64-bit support in Visual Studio is installed Re-Build the sources and check the executable with MS Depends again and it should show small 64 numbers if the module is for a 64-bit platform.

I use dependency walker. I open "....3d\x64\Debug\3d\3d.exe file.  It gives only "Could not find the section that own the Import directory" warning.

Can you run dumpbin or LordPE. on the 3d.exe  IAT table?It seems that dependency walker has a problem with finding imports section or it could be also packed executable.

0 Kudos
emreka82
Beginner
3,534 Views

Sergey Kostrov wrote:

>>...I use dependency walker. I open "....3d\x64\Debug\3d\3d.exe file. It gives only "Could not find the section that own the Import
>>directory" warning...

Could you post a screenshot? Unfortunately, I don't have a Crystal Ball and I can not see what is going on with MS Depends or your computer

The screenshot is attached.

Sergey Kostrov wrote:

Note: I use the test project to test my system and more than 128GB of memory successfully allocated when two 64Kx64K matricies multiplied

I use it with a 48 GB virtual memory, two 16Kx16K matrices are multiplied successfully.

0 Kudos
emreka82
Beginner
3,534 Views

iliyapolak wrote:

Can you run dumpbin or LordPE. on the 3d.exe  IAT table?It seems that dependency walker has a problem with finding imports section or it could be also packed executable.

I use dumpbin. The output is as follows:

C:\Program Files\Microsoft Visual Studio\VC98\BIN>dumpbin/out:E:\3d\3d\3d\x64\Debug/3d.exe
Microsoft (R) COFF Binary File Dumper Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

After that, the dependency walker gives error again. The screenshot is attached.

0 Kudos
SergeyKostrov
Valued Contributor II
3,534 Views
>>...I use it with a 48 GB virtual memory, two 16Kx16K matrices are multiplied successfully. It is a good news. Now, please take a look at another useful option of the Intel Visual Fortran compiler ( in a Visual Studio ): Configuration Properties -> Fortran -> Code Generation -> Enable Recursive Routines = Yes Regarding a problem with MS Depends: - If you're using a computer with Windows 7 operating system open the Windows Task Manager and take a look at a list of programs and all 32-bit programs will have suffix *32. For example: - If you see 3D.exe *32 - this is the 32-bit program - If you see 3D.exe - this is the 64-bit program Could you attach 3D.exe ( Release configuration(s) in a ZIP file! ) for my review with MS Depends?
0 Kudos
Bernard
Valued Contributor I
3,534 Views

>>>After that, the dependency walker gives error again. The screenshot is attached>>>

Could that be a parsing error?.What is the output produced by dumpbin?Can you download a free IDA PRO version and parse 3d.exe PE file?

While working with IDA you need to look for "MZ" ASCII identifier (0x5A4D in hex).

0 Kudos
Bernard
Valued Contributor I
3,534 Views

>>>C:\Program Files\Microsoft Visual Studio\VC98\BIN>dumpbin/out:E:\3d\3d\3d\x64\Debug/3d.exe Microsoft (R) COFF Binary File Dumper Version 6.00.8447 Copyright (C) Microsoft Corp 1992-1998. All rights reserved.>>>

Is the output above the only output produced by dumpbin?

0 Kudos
emreka82
Beginner
3,534 Views

iliyapolak wrote:

@emreka82

Why do not you try to use windbg and application verifier in order to automate the error finding task.

Hi iliya,

I tried all the suggestions and cannot progress. So, I will try the Windows SDK installation as you suggested. Can you help me with the procedure to follow while searching for the problem ? Thanks.

Emre

0 Kudos
Bernard
Valued Contributor I
3,474 Views

Yes I will help you.

What have you already done can you describe me?

0 Kudos
emreka82
Beginner
3,474 Views

iliyapolak wrote:

Yes I will help you.

What have you already done can you describe me?

I open Windbg(x64) now, and open executable file (3d) (...File....Open Executable). The output is:


Microsoft (R) Windows Debugger Version 6.2.9200.20512 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: E:\3d\3d\3d\x64\Debug\3d.exe
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path. *
* Use .symfix to have the debugger choose a symbol path. *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
ModLoad: 00000001`3fec0000 00000001`40672000 3d.exe
ModLoad: 00000000`778f0000 00000000`77a99000 ntdll.dll
ModLoad: 00000000`77420000 00000000`7753f000 C:\Windows\system32\kernel32.dll
ModLoad: 000007fe`fe070000 000007fe`fe0db000 C:\Windows\system32\KERNELBASE.dll
ModLoad: 000007fe`fea80000 000007fe`fea99000 C:\Windows\system32\imagehlp.dll
ModLoad: 000007fe`fe120000 000007fe`fe1bf000 C:\Windows\system32\msvcrt.dll
ModLoad: 000007fe`fed80000 000007fe`fee5b000 C:\Windows\system32\ADVAPI32.dll
ModLoad: 000007fe`fea60000 000007fe`fea7f000 C:\Windows\SYSTEM32\sechost.dll
ModLoad: 000007fe`fe2f0000 000007fe`fe41d000 C:\Windows\system32\RPCRT4.dll
(1764.16c0): Break instruction exception - code 80000003 (first chance)
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -
ntdll!CsrSetPriorityClass+0x40:
00000000`7799cb60 cc int 3

0 Kudos
Bernard
Valued Contributor I
3,474 Views

>>>CommandLine: E:\3d\3d\3d\x64\Debug\3d.exe Symbol search path is: *** Invalid ***>>>

You need to set valid symbol path.For casual debugging the best option is to use microsoft debug symbol server.Please at debug console enter this command: .sympath SRV*c:\symbols folder name*http://msdl.microsoft.com/download/symbols  , next execute .reload command.

0 Kudos
Reply