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?
> 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
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.
> 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
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.
The operating system was 2003 Server.
MB.
> 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
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
...
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 (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...
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
"Alan Carre" <al...@twilightgames.com> wrote in message
news:uUXuj6JW...@TK2MSFTNGP06.phx.gbl...
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