Alexander
Wed Oct 17 06:36:38 PDT 2007
By the way, KeStackAttachProcess' first argument is PKPROCESS, not PCB.
And I would not put magic numbers into __except(). If 1 means
EXCEPTION_EXECUTE_HANDLER, you should write
__except(EXCEPTION_EXECUTE_HANDLER)
You may also want to call KeEnterCriticalRegion, to prevent your thread from
being terminated while in the process context.
"L. Spiro" <LSpiro@discussions.microsoft.com> wrote in message
news:67AA2D6D-02F1-4C68-A41D-6CFA0018F9FB@microsoft.com...
> My code looks like this:
>
> if ( NT_SUCCESS( NtStatus ) ) {
> KeStackAttachProcess( &Process->Pcb,
> &pState );
>
> NtStatus = STATUS_SUCCESS;
> __try {
> NtStatus = STATUS_PARTIAL_COPY;
> RtlCopyMemory( Irp->AssociatedIrp.SystemBuffer,
> BaseAddress,
> NumberOfBytesToRead );
> NtStatus = STATUS_SUCCESS;
> }
> __except( 1 ) {
> if ( NtStatus != STATUS_PARTIAL_COPY ) {
> NtStatus = STATUS_UNSUCCESSFUL;
> }
> }
> KeUnstackDetachProcess( &pState );
> }
>
> (I verify the size of Irp->AssociatedIrp.SystemBuffer beforehand and do
> other various checks so it is definitely not an overflow of that buffer or
> anything simple such as that.)
> So KeStackAttachProcess() is definitely always matched with
> KeUnstackDetachProcess().
>
>
>
>> If you comment out the code that accesses user mode memory do you
>> still deadlock?
>
> I haven't tried this after discovering 0x7FFE0000 as being the cause.
> Previously, removing RtlCopyMemory() saved me from some problems but I
> think
> those were caused by other things I have since fixed and I wasn't
> specifically looking at 0x7FFE0000 then. I'll have to try it.
>
>
>> Have you tried locking down the user mode memory using a MDL before
>> attempting to access it?
>
> I haven't yet since I have been relying on __try/__except to get out of
> trouble memory spots and it has been working except for this problem.
>
>
>
> This problem only happens on the 0x7FFE0000 chunk of shared memory, so
> because of its exceptional properties I don't know enough to really figure
> out the exact cause of the deadlock or how to fix it. I also don't want
> to
> run away from the problem by just denying reading of that area.
> Would MmProbeAndLockPages() be the solution for this (and all other)
> section(s) of RAM?
>
>
>
>
> After reading
http://www.microsoft.com/whdc/Driver/tips/MmProbe.mspx I
> have
> a few questions.
> MmProbeAndLockPages() verifies the addresses for me, right? Which means
> after I get the lock I can be sure that it will not throw any exceptions
> if I
> read from the pointer it gives me, right?
>
> Looking at a few examples, I don't see how MmProbeAndLockPages() is
> locking
> the address from where I want to read. I see examples such as this:
>
>
> Mdl = MmCreateMdl(NULL,
> Buffer, // <-- This is the address where they store the data after
> they read it.
> BytesToRead);
> ...
> MmProbeAndLockPages(Mdl, // <- Still no lock on the data they intend to
> read.
> PreviousMode,
> IoWriteAccess);
> ...
> KeAttachProcess(&Process);
> SystemAddress = MmGetSystemAddressForMdl(Mdl);
> RtlCopyMemory(SystemAddress, ReadAddress, BytesToRead);
> KeDetachProcess();
>
>
>
> In this example I fail to see how ReadAddress (the address from which they
> want to read in the target process) has been locked. They locked the
> buffer
> where they want to store the data instead, which I assume is because they
> passed that address as a virtual address from the original process and
> they
> need to make it kernel so they can write to it while in the target
> process.
>
> Is this not to be used as I originally thought, or will I be safe to use
> their example, but swap the lock to be the read address instead of the
> write
> address (their example actually does the same thing my code is trying to
> do,
> which is why I considered it a valid example).
>
> I just want to ask this to be sure I don't make a stupid mistake since I
> haven't used these functions yet.
>
>
>
> Regards,
> L. Spiro