forums.silverfrost.com

JosephHarris · Joined: 21 Jul 2011 Posts: 8

Hello,

I am currently trying to run some code (that i didn't write, just modified), which compiles with no errors, but won't run.

Instead i get an error screen which says:

Access Violation
The instruction at address 114422bd attempted to write to location 65403000

114422bd routine at address 114422BD [+0000]

while the error.txt file adds:

Access Violation
The instruction at address 114422bd attempted to write to location 65403000

114422bd routine at address 114422BD [+0000]

eax=65403000 ebx=0363e400 ecx=1144257c
edx=114422b8 esi=114422b8 edi=114426c4
ebp=00406bf0 esp=0363e314 IOPL=1
ds=0023 es=0023 fs=003b
gs=0000 cs=001b ss=0023
flgs=00010206 [NC EP NZ SN DN NV]

114422bd addb [eax],al
114422bf addb [eax],al
114422c1 addb [eax],al

I realise that at some point the program is struggling to write to a location, and this causes the error. My question is, how do i find out when this routine occurs? I've tried commenting out all the 'WRITE' lines, but i assume it's more complicated than that.

This 114422bd seems to be the trouble, but where is it?

I tried using Checkmate Win32, Debug Win32 and Release Win32, but they all get the same error. The debug screen just highlights the line red:

759cd36f LEAVE +00000

And i can't click on anything else. I get the exception in the Call Stack:

0xA1A01DB1 *unknown*

Apologies if none of this is useful, i am quite the beginner at this.

Many thanks in advance if anybody manages to make sense of all this.

Joe

PaulLaidler · Posted: Mon Jul 25, 2011 1:58 pm Post subject:

Use CHECKMATE and start up the executable using the debugger SDBG.
You can do this in Plato by clicking on the green arrow button on the Build toolbar.

In the debugger, click on the "Run" button. The program should then stop at the line that is causing the problem.

JosephHarris · Joined: 21 Jul 2011 Posts: 8

When i try move into the debugger window, the 'run' button is greyed out and cannot be clicked.

In fact, nothing I click in the debugger window does anything.

This is what I see:

What might this mean? Have I set it up wrongly?

PaulLaidler · Posted: Mon Jul 25, 2011 5:05 pm Post subject:

Try compiling and linking with /CHECKMATE and then run SDBG from a command line...

SDBG myprog.exe

JosephHarris · Joined: 21 Jul 2011 Posts: 8

Apologies for the slow reply.

I tried running the SDBG from the command line and got the same result...

PaulLaidler · Posted: Tue Jul 26, 2011 6:12 pm Post subject:

If you can reproduce the error in a few lines of code then you can post the code here and I will look at it.

JosephHarris · Joined: 21 Jul 2011 Posts: 8

Hi,

The program I am trying to run uses NAG routines, so unless you have a NAG licence, I doubt you'll be able to reproduce the error.

Assuming that it was something in my code that was messing it up, I tried running the example program provided by NAG for the routine I want to use. It ended up with the same result, so presumably the problem is with using the NAG routine?

I appreciate the effort in trying to help though!

Joe

PaulLaidler · Posted: Wed Jul 27, 2011 3:18 pm Post subject:

Let me have a short sample program that illustrates the problem together with the compiler command line options that you have used. I may still have access to the NAG library. If not I may be able to see what is wrong without it.

sparge · Joined: 11 Apr 2005 Posts: 371

OK, I understand the problem now (bit slow sometimes). The program doesn't do something and then fall over. It fails as soon as it begins to execute?

This might or might not help ... leave SDBG out of the equation and run (any flavour of) your executable under control of Dependency Walker:

http://www.dependencywalker.com/

It is a excellent diagnostic tool that has shed valuable light for me on many weird runtime issues. It won't (can't) pinpoint an offending line of source code, but it may well indicate at a higher level where the problem is occurring i.e. the DLL. It would be uncommon (although not unheard of) for SDBG to be unable to do this if it was a line of your code that was the villain of the piece.

Andy

JosephHarris · Joined: 21 Jul 2011 Posts: 8

http://www.filehosting.org/file/details/251227/roughdiskcode.f95

The above is my program. I could have pasted the code in here, as it's not that long, but i thought this might be easier?

http://www.filehosting.org/file/details/251226/uvw101_NEW.txt

You might need this file, as it tries to read from it at some point, but i get the same result whether this file is present or not.

I compiled the above using:

ftn95 /f_stdcall /mod_path nag_interface_blocks_ftn95 roughdiskcode.f95 /import_lib "C:\Program Files\NAG\FL23\fldll234ml\bin\FLDLL234M_mkl.dll" /link

And then ran it using:

SDBG roughdiskcode.exe

And that gives me the aforementioned debugger window.

Thanks!

EDIT: Just saw Andy's post, i will try that now, thanks!

JosephHarris · Joined: 21 Jul 2011 Posts: 8

That Dependency program is amazing.

Ok, bizarre as it may seem, the problem was being caused by a missing .dll file used in Internet Explorer 9.... no idea why.

So i reinstalled IE9 (i don't even use it) and now the program runs fine.

It seems Microsoft are so intent on getting people to use IE that they disable your other programs until you have it running properly.

Thanks for all your help both of you,

Joe

sparge · Joined: 11 Apr 2005 Posts: 371

Woohoo ... glad you got it sorted. And yes, Dependency Walker is awesome. As an afterthought, it would be interesting to see what other compilers make of your code. A missing DLL is a completely routine abnormal situation for a program to encounter - try running some othr programs under Dependency Walker and I'll be surprised (astonished) if every one you choose doesn't encounter several, many many times during execution. I've never found one yet that doesn't. It seems to me that the finger of blame points at the exe, hence at the compiler, not the missing DLL.