Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Application Error, The memory could not be "read". How to debug?

379 views
Skip to first unread message

MB

unread,
Nov 14, 2007, 5:54:27 PM11/14/07
to
Our application, which runs as a service, has given the following
Application Error just once, randomly, while shutting down the service on a
customer machine:

The instruction at "0x7c82caa2" referenced memory at "0xffffffff". The
memory could not be "read".

Is there anything that can be gleaned from that address? Does Windows or Dr.
Watson write any further information about this type of error anywhere? The
event log shows no further information and I could not locate a Dr. Watson
entry. There are Dr. Watson entries for other errors, so it is turned on.
Should Dr. Watson create a log entry for this type of error? If so, perhaps
I was looking in the wrong place. Where can I find it's log for the local
system account?


Remy Lebeau

unread,
Nov 14, 2007, 7:00:00 PM11/14/07
to

"MB" <b...@bla.bla> wrote in message
news:OgK3zFxJ...@TK2MSFTNGP02.phx.gbl...

> Is there anything that can be gleaned from that address?

Your code is trying to read a value from memory using an invalid pointer.
If you were reading from a NULL pointer, that would result in a read at
address 0x00000000. 0xFFFFFFFF is 1 less than 0 when treated as an unsigned
value, so that suggests you are probably subtracting 1 byte from a NULL
pointer, such as by using index -1 into a dynamically allocated array that
is pointed to by a NULL pointer.

As for 0x7c82caa2, that is the memory address of the actual code instruction
that is performing the read. Im not sure about VC++, but Borland compilers
(which I use) have an option to output a .map file. That sometimes helps
isolate the offending section of code.

> Does Windows or Dr.Watson write any further information about this type of
> error anywhere?

Not that I know of.


Gambit


MB

unread,
Nov 14, 2007, 7:45:18 PM11/14/07
to
Gambit,

Thanks. Also using the Borland compiler. Map file and debugger show code
starting at 0x00401000. The old td32 debugger (on my own machine, Win2k)
cannot even read from address 0x7c82caa2, it only displays question marks.
But if that address range so far up doesn't even exist, shouldn't Windows
complain about trying to access that address rather than an instruction at
that address doing something wrong? Does any Windows system code (DLL?) get
mapped into that address range, but protected so the debugger can't read it?
Or does Win2k3 server behave differently from Win2k?

As an aside, googling that address shows some versions of PHP generating a
similar error. Probably a useless bit of trivia, right? Obviously my
application != PHP.

MB.


Remy Lebeau

unread,
Nov 14, 2007, 9:07:56 PM11/14/07
to

"MB" <b...@bla.bla> wrote in message
news:Opl%23WDyJI...@TK2MSFTNGP05.phx.gbl...

> Thanks. Also using the Borland compiler. Map file and debugger show code
> starting at 0x00401000.

If I remember correctly (been awhile since I used .map files), it contains
relative offsets, so add the program's starting address to them to get
anything meaningful out of them.


Gambit

MB

unread,
Nov 14, 2007, 9:17:46 PM11/14/07
to
Indeed. I've already done that. The relative offsets start with zero. The
program's starting address is 0x00401000. Also verified using the debugger.


Microsoft

unread,
Nov 15, 2007, 2:31:17 AM11/15/07
to
Dr. Watson can create a (mini) dump file. Should your debugger support minidump, it will take you to the exact location of the crash, with call history (so you can trace back to your code that caused the crash). Microsoft's debugger does support minidumps, but I don't know about Borland's.

Considering the address, the crash occures in some DLL, not in your code, so map file won't help (unless your service uses your own DLL(s) and the crash is in it).


"MB" <b...@bla.bla> wrote in message news:OgK3zFxJ...@TK2MSFTNGP02.phx.gbl...

Tim Roberts

unread,
Nov 15, 2007, 11:59:07 PM11/15/07
to
"MB" <b...@bla.bla> wrote:
>
>Our application, which runs as a service, has given the following
>Application Error just once, randomly, while shutting down the service on a
>customer machine:
>
>The instruction at "0x7c82caa2" referenced memory at "0xffffffff". The
>memory could not be "read".
>
>Is there anything that can be gleaned from that address?

The addresses just under the 2GB mark are occupied by the system DLLs. If
you are running Windows XP, this is kernel32.dll (which starts at
7C800000).

I can't tell what routine it is, but it calls NtSetInformationJobObject so
it must be modifying some process state.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

MB

unread,
Nov 16, 2007, 9:44:11 AM11/16/07
to
This is interesting. Thank you.

The operating system was 2003 Server.

MB.


Remy Lebeau

unread,
Nov 16, 2007, 2:22:22 PM11/16/07
to

"Tim Roberts" <ti...@probo.com> wrote in message
news:1n8qj3psp8bj07eeu...@4ax.com...

> The addresses just under the 2GB mark are occupied by the
> system DLLs. If you are running Windows XP, this is kernel32.dll
> (which starts at 7C800000).

Is there a list somewhere that specifies which OS DLLs run at which
addresses?


Gambit


Tim Roberts

unread,
Nov 17, 2007, 6:30:44 PM11/17/07
to

No, but you can find out by asking. That's what I did. (Actually, that's
not quite true; I loaded a dummy program into OllyDbg. OllyDbg includes a
window that shows the base address of all of the currently loaded modules,
in numerical order.)


C:\Dev>link /dump /headers \WINDOWS\system32\kernel32.dll
Microsoft (R) COFF/PE Dumper Version 8.00.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.


Dump of file \WINDOWS\system32\kernel32.dll

PE signature found

File Type: DLL

FILE HEADER VALUES
14C machine (x86)
4 number of sections
46239BD5 time date stamp Mon Apr 16 08:52:53 2007
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
210E characteristics
Executable
Line numbers stripped
Symbols stripped
32 bit word machine
DLL

OPTIONAL HEADER VALUES
10B magic # (PE32)
7.10 linker version
82200 size of code
70000 size of initialized data
0 size of uninitialized data
B5AE entry point (7C80B5AE)
1000 base of code
7F000 base of data
7C800000 image base (7C800000 to 7C8F4FFF) <<<<<<
1000 section alignment
200 file alignment
...

Emil

unread,
Dec 5, 2008, 3:02:54 PM12/5/08
to
Hi I have the same problem with my application.

I developed an application with Borland C++.
And I've got the following error:

Myapp.exe_Application Error
The instruction at 0x0044f73d referenced memory at 0x00000049.
The memory can not be written.

I checked the map File. The address brought me to VCL50.LIB|Controls.

I don't know what does it mean??? The VLC50.lib is a standard Borland package.
what can I do to find where exactly the error occurs. Need i change my project options???

please help

Don Burn

unread,
Dec 5, 2008, 3:08:13 PM12/5/08
to
And I would guess you passed in a NULL pointer to a routine in that library,
and it is trying to reference offset 0x49 from that pointer.


--
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply


<Emil> wrote in message news:2008125152...@hotmail.com...

Alan Carre

unread,
Dec 7, 2008, 2:04:32 PM12/7/08
to
<Emil> wrote in message news:2008125152...@hotmail.com...

This one should jump out at you like a rabbit out of a hat! (well almost)
0x49 is clearly a dialog resource identifier that you've cast as a string.
Find out which resource(s) in your program have ID == 73 (decimal) and make
sure you use the appropriate CreatDialog functions using the MAKEINTRESOURCE
macro for your ID's [though simple cast to int *should* work in theory].

Actually, it is a bit strange though... usually resource ID's start at 101
for dialogs, and 300s or something for controls (something like that). 73 is
quite unusual. Happens to correspond to the letter 'I'. As in
"[I]DD_DIALOG1"... where you may be using UNICODE strings?... not sure.

- Alan Carre


Alexander Grigoriev

unread,
Dec 7, 2008, 2:12:41 PM12/7/08
to
Usually this is a reference to a structure member through a NULL pointer. Of
course, a debugger would show that instantly.

"Alan Carre" <al...@twilightgames.com> wrote in message
news:uUXuj6JW...@TK2MSFTNGP06.phx.gbl...

Alan Carre

unread,
Dec 7, 2008, 2:50:09 PM12/7/08
to
"Alexander Grigoriev" <al...@earthlink.net> wrote in message
news:uzhgH$JWJHA...@TK2MSFTNGP05.phx.gbl...

> Usually this is a reference to a structure member through a NULL pointer.
> Of course, a debugger would show that instantly.

Ya, but the lib is : VCL50.LIB|Controls

And integers are often used as control ID's rather than strings (you can
pass a string ID too of course). That's why I thought it looked like a mixup
between string ID and numeral ID for a dialog resource. Also the fact that
it was the letter "I" (capital) made me think that either he'd called
MAKEINTRESOURCE on an actual string, or forgotten to on an numeric ID.

Guess we'll never know...

- Alan Carre


0 new messages