SEH message

[jj2007]

Hi everybody

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

Code Select Expand

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):

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

[sinsi]

So 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!

[jj2007]

Thanks, Sinsi

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

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:

Ouch, 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:

Code Select Expand

mov ecx, 4097
rep movsb
Funnily enough, the macro in question had the "replace placeholders" feature already implemented, but a tiny glitch prevented it from working

[zedd151]

Jochen, you might find this interesting: https://masm32.com/board/index.php?msg=71138 

Why the sudden interest? 

[jj2007]

Yes, of course. I'm not a fan of SEH, bad code should crash and scare the dumb user. It's more academic interest

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

[zedd151]

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.

[sinsi]

I doubt that Visual Bulls*it has that feature

That, and more

[NoCforMe]

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:

You cannot view this attachment.

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???

[jj2007]

When 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...

[NoCforMe]

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?

[TimoVJL]

Run trace

[jj2007]

No returns from my code

Bad luck. Use a macro:

Code Select Expand

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 start
For 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.

[zedd151]

Thanks. 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.