push dword ptr [esp+0Ch] ss:0010:b6875bd4=00000018

[hackkaush]

Hello all,

I guess this will be the best group to discuss this with. I have got
an access violation while running Windows OS.

kd> r
eax=81350030 ebx=00000000 ecx=00000000 edx=0006fac0 esi=00000000
edi=810f6648
eip=8048f2ab esp=b6875bc8 ebp=b6875c2c iopl=0 ov up ei ng nz
na pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010a87
nt!ExMapHandleToPointer+0x1:
8048f2ab ff74240c push dword ptr [esp+0Ch] ss:
0010:b6875bd4=00000018

kd> dd @esp+0x0c
b6875bd4 00000018 00000000 00000000 804a7301

Now the instrucution where it gave access violation is
push dword ptr [esp+0Ch]

and the address it says is:

kd> r cr2
cr2=00000018

Now if understand the instruction right it means that push the value
contained at the address "esp+0x0C" on the stack. So why is the
processor trying to write to address "0x18" which is actually the
value.

This is a write access violation.

Any help will be appreciated.

Thanks,
Puneet

[Terence]

I think you are trying to do two memory operations at the same time
(read contents of memory and store those two words in the memory stack
at that other memory address.

It doesn't work that way.
You have to put the double pointer you want to use in appropriate
registers and then push those registers.

So the assmbler is misinterpreting the instruction as immediate and
not indirect.

[CodeMonk]

I had a similar problem which I solved thusly:

mov ecx,dword ptr[puidSize] ; puidSize = pointer on stack
mov dword ptr[ecx],eax

Not sure if this would help you or even if this is the correct
solution, but it got me out of a pickle I didn't have time to deal
with. I'm going to take Terence's input and go revisit that module.

Also, since your playing with the ntoskrnl - you're in way over my
head anyway.

- Scott

[x87asm]

"Terence" <spam...@crayne.org> wrote in message
news:1185495052.2...@19g2000hsx.googlegroups.com...

no... I was pondering this one all day today...

the instruction is legal and coded properly

all the OP said is that it gives an access violation

Without knowing more, I'd say it's either #SS from accessing a memory
address outside the limit of the stack segment, or #PF due to a page
fault... if it was a #PF, there would've been a special error code dropped
onto the stack...

--
Bx.C / x87asm

[CodeMonk]

I realized right after i clicked send that we are also discussing
opposite sides of the invocation. I knew I'd had the same problem,
but I put my fingers in motion before my brain in gear. Whoops :)

- Scott

[Tim Roberts]

hackkaush <spam...@crayne.org> wrote:
>
>I guess this will be the best group to discuss this with. I have got
>an access violation while running Windows OS.
>
>kd> r
>eax=81350030 ebx=00000000 ecx=00000000 edx=0006fac0 esi=00000000
>edi=810f6648
>eip=8048f2ab esp=b6875bc8 ebp=b6875c2c iopl=0 ov up ei ng nz
>na pe cy
>cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
>efl=00010a87
>nt!ExMapHandleToPointer+0x1:
>8048f2ab ff74240c push dword ptr [esp+0Ch] ss:
>0010:b6875bd4=00000018

What was the bugcheck code? Was it a C0000005, or was it a
IRQL_LESS_EQUAL? It's possible, for example, that b6875bd4 is a pageable
address but you were at a raised IRQL.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Terence]

On Jul 27, 12:14 am, hackkaush <spamt...@crayne.org> wrote:

> Now the instrucution where it gave access violation is
> push dword ptr [esp+0Ch]
>
> and the address it says is:
>
> kd> r cr2
> cr2=00000018
>
> Now if understand the instruction right it means that push the value
> contained at the address "esp+0x0C" on the stack. So why is the
> processor trying to write to address "0x18" which is actually the
> value.
>
> This is a write access violation.

My reply was based on a lot of AT knowledge in early ASM where double
memory operations were not possible (and therefore not in the ASM
syntax). Of course the CPU can take an operation and execute it
internally it partial operations (as it really does anyway) using its
own inaccessable registers (and there's far more of these nowadays).

But I concentrated on the OP's obervation that the cpu was trying to
write the address itself and not the contents of the address, so I
inferred a bug in the assembler when meeting an unusual instruction
form, and so the code with (to me) an illegal opearation, even it
those kinds of complex operations may be allowed now in newer chips
and assemblers. I still use an MS 1985 assembler code for my current
work since most is done using DOS emulation on whatever cpu is
offered.

[CodeMonk]

This is what I tried to do originally:

==============================
option casemap:none
option proc:private
..386
..model flat,stdcall

foo proto :PTR DWORD
bar proto :PTR DWORD

..data

uidSize dd 1234678h

..code

entry:

invoke foo, offset uidSize
invoke bar, offset uidSize
ret

; In my situation, these procs
; are normally in a separate module

foo proc puidSize:PTR DWORD
mov eax,[puidSize]
ret
foo endp

; Hoped eax = 12345678h

bar proc puidSize:PTR DWORD
neg eax
mov [puidSize],eax
ret
bar endp

; Hoped [uidSize] = EDCBA988h

end entry
==============================

Both hopes were dashed, but hopefully the intent is obvious. Since
this didn't work, I tried something different which resulted in the
same access violations described by the OP. I did manage to solve my
problem, but I still don't understand why the code here didn't work.

[CodeMonk]

This is just a heads-up in case you try to paste the code into an
editor. I don't know why the directives in the sample code are
prefaced with two dots. When I posted they only had one.

- Scott

[Frank Kotler]

CodeMonk wrote:
> This is what I tried to do originally:
>
> ==============================
> option casemap:none
> option proc:private
> ..386
> ..model flat,stdcall
>
> foo proto :PTR DWORD
> bar proto :PTR DWORD
>
> ..data
>
> uidSize dd 1234678h
>
> ..code
>
> entry:
>
> invoke foo, offset uidSize
> invoke bar, offset uidSize
> ret
>
> ; In my situation, these procs
> ; are normally in a separate module
>
> foo proc puidSize:PTR DWORD
> mov eax,[puidSize]

Take a look at the listing file (or a disassembly) and see what you'r
assembler's producing for this. I'd bet on:

mov eax, [ebp + 8]

Which means you've got to "dereference the pointer":

mov eax, [eax]
ret

To go the other way:

mov ecx, [puidsize] ; [ebp + 8]
neg eax
mov [ecx], eax
ret

(we're fairly used to leading "."s doubling - or disappearing. A
mismatch in news clients, I think. annoying, but we can compensate.)

Best,
Frank

[CodeMonk]

>> but I still don't understand why the code here didn't work

Relating to my understanding of what I thought Masm's INVOKE brings to
the table. Clearly my understanding of the benefits of INVOKE were
inflated :)

Ultimately, I did deference the pointer as in my original reply under
this topic:

>> mov ecx,dword ptr[puidSize] mov dword ptr[ecx],eax

But not before stumbling into the pitfall encountered by the OP.
Anyway, thanks for the thoughts.

- Scott

[Jim Carlock]

"CodeMonk" wrote:
: This is what I tried to do originally:

:
: ==============================
: option casemap:none
: option proc:private
: ..386
: ..model flat,stdcall

<snip>...</snip>

Those should be?

option casemap:none
option proc:private

.386
.model flat,stdcall

--
Jim Carlock