Hi everybody :biggrin:
I'm playing with Structured Exception Handling and need help because one message I get is slightly cryptic. So I'd like to google it, but... I get it in Italian :sad:
The OS reports:
L'istruzione a 0x%p ha fatto riferimento alla memoria a 0x%p. La memoria non poteva essere %s.
Pretty straightforward, but to perform a "phrase search" I need the exact wording in English.
Source and executable attached. Please run the exe and copy the message.
The source (uses Try/Catch/Finally (https://www.jj2007.eu/MasmBasicQuickReference.htm#Mb1217)):
include \masm32\MasmBasic\MasmBasic.inc
Init tc ; initialise with try/catch enabled
Cls 3 ; three empty lines please
invoke VirtualAlloc, 0, 4096, MEM_COMMIT, PAGE_READWRITE
xchg eax, edi
Let esi=FileRead$("\Masm32\examples\exampl01\generic\generic.asm")
count=4095
REPEAT 4
Try
push edi
mov ecx, count ; 4095, 4096, 4097...
count=count+1
rep movsb
pop edi
PrintLine Str$("So far, so good: the string is %i bytes long", Len(edi))
Catch
PrintLine Str$("\nOuch, we had an exception in source line %i at\nAddress\t", LastEx(line)), Hex$(LastEx(addr)), CrLf$, "Code", Tb$, Hex$(LastEx(code)), CrLf$
PrintLine "The OS reports:", CrLf$, LastEx(info)
Finally
ENDM
Inkey cfm$("\nThat was fun, yeah\x")
EndOfCode
QuoteSo far, so good: the string is 4095 bytes long
So far, so good: the string is 4096 bytes long
Ouch, we had an exception in source line 0 at
Address 00401548
Code C0000005
The OS reports:
The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.
EIP 00401548
Code C0000005
Ouch, we had an exception in source line 0 at
Address 0040173F
Code C0000005
The OS reports:
The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.
EIP 0040173F
Code C0000005
That was fun, yeah!
Thanks, Sinsi :thumbsup:
Now I get plenty of hits for The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.
When modifying the phrase search to...
"The instruction at " "referenced memory at" "The memory could not be"
... i.e.taking out the placeholders, I get even more hits, e.g. The instruction at 0x00007FF98EF219A4 referenced memory at 0xFFFFFFFFFFFFFFFF. The memory could not be read (https://answers.microsoft.com/en-us/windows/forum/all/the-instruction-at-0x00007ff98ef219a4-referenced/3797302c-35a7-4bf8-aaeb-55dbe3ec6735)
Now the questions are:
1. Why do many applications
not use the placeholders to insert the values?
2. How do some applications insert the correct values there?
3. How do they deal with The instruction at 0x%p referenced memory at 0x%p, i.e. twice the same placeholder for different issues?
P.S.:
Question 2 solved, see attachment - it works:
QuoteOuch, we had an exception in source line 34 at
Address 00401560
Code C0000005
The OS reports:
The instruction at 00401560 referenced memory at 001F1000. The memory could not be written.
Line 33+34:
mov ecx, 4097
rep movsbFunnily enough, the macro in question had the "replace placeholders" feature already implemented, but a tiny glitch prevented it from working :cool:
Jochen, you might find this interesting: https://masm32.com/board/index.php?msg=71138 (https://masm32.com/board/index.php?msg=71138) :biggrin:
Why the sudden interest? :tongue:
Yes, of course. I'm not a fan of SEH, bad code should crash and scare the dumb user. It's more academic interest :cool:
But it was fun coding that stuff. Especially the RichMasm feature that the cursor jumps to the line where the exception occurred. I doubt that Visual Bulls*it has that feature :bgrin:
Yeah, I couldn't think of anyone here that does use SEH on a regular basis in their assembly code, when it was brought up in another thread.
Quote from: jj2007 on March 18, 2025, 01:00:30 AMI doubt that Visual Bulls*it has that feature :bgrin:
That, and more :biggrin:
While we're on the topic of SEH, I wonder if someone can help out with this aspect of hunting down errors.
I'm getting a consistent fault with a program of mine. When I open Olly (through the Windows error-handling dialog), I see the following stack trace:
Olly stack.gif
The error is obviously occurring in ntdll.dll. But I have no frigging idea what to do with this. The current stack pointer is at the top, and I know that everything below that goes back in time. Apart from that I have no idea how to "unwind" the stack or use this to try to find out what was called from where. (And I do think that some of this stuff includes SEH along the way.)
Help???
Quote from: NoCforMe on March 18, 2025, 08:14:10 AMWhen I open Olly (through the Windows error-handling dialog), I see the following stack trace:
Try to find another red RETURN that points to your own code. That can be pretty far down...
Thanks. Just looked at another crash, and all the returns are from ntdll.
And then the stack display just ends. No returns from my code.
Do I need to do something to embiggen Olly's stack display?
Run trace (https://www.ollydbg.de/Tut_rtr.htm)
Quote from: NoCforMe on March 18, 2025, 09:05:39 AMNo returns from my code
Bad luck. Use a macro:
include \masm32\include\masm32rt.inc
uselog=1
log MACRO
if uselog
pushad
print "this is line "
print str$(@Line), 13, 10
popad
endif
ENDM
.data
MyArray dd 25, 18, 23, 17, 9, 2, 6
HelloW$ db "Hello World", 0
.code
start:
log
xor ebx, ebx ; set two non-volatile
xor esi, esi ; registers to zero
log
.Repeat
add esi, MyArray[4*ebx]
inc ebx
.Until ebx>=lengthof MyArray
log
MsgBox 0, cat$(str$(esi), " is the sum"), offset HelloW$, MB_OK
exit
end startFor uselog=0, it doesn't generate any code. Of course, you SUBSYSTEM:CONSOLE. Just insert log before any call or invoke, and after a while you'll find out after which call the logging stops.
Quote from: NoCforMe on March 18, 2025, 09:05:39 AMThanks. Just looked at another crash, and all the returns are from ntdll.
And then the stack display just ends.
Is the stack getting overwritten somehow?
Are you using a lot of stack memory? (Huge local buffers) If yes increase the stack size when linking.
ex: /STACK:0x800000,0x800000 in link.exe command line args
You can try it. It can't hurt. Report your findings if it helped or not.