Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Access Violation on local Var, when trying to wait for a thread

AaronKAaronK Member Posts: 19

Hello everyone!

I have had some problems with a little piece of my code and I need some help finding the source of it.
My relevant Code looks like this, shortened for Brevity:

VOID CopyJobThread(){
  NTSTATUS Status = 0;
  HANDLE ThreadHandle1 = NULL;
  PKTHREAD ThreadObject1 = NULL;
  OBJECT_ATTRIBUTES ObjectAttributes;


  * Set some values, allocate Buffers *

  InitializeObjectAttributes( &ObjectAttributes, NULL, OBJ_INHERIT | OBJ_KERNEL_HANDLE, NULL, NULL );

  Status = PsCreateSystemThread( &ThreadHandle1, THREAD_ALL_ACCESS, &ObjectAttributes, NULL, NULL, CopyJobWrite, &PFileContext->CopyInternals.CopyBuffer[0] );
  if(!NT_SUCCESS( Status )) {
    ThreadHandle1 = NULL;
    goto cleanup;
  }

  Status = ObReferenceObjectByHandle( ThreadHandle1, THREAD_ALL_ACCESS, *PsThreadType, KernelMode, &ThreadObject1, NULL );

  if(!NT_SUCCESS( Status )) {
    ThreadObject1 = NULL;
    goto cleanup;
  }


  * Loop a Read and send data to CopyJobWrite untill EOF *


  if(ThreadObject1 != NULL) {
    KeWaitForSingleObject( ThreadObject1, Executive, KernelMode, FALSE, NULL );
    ObDereferenceObject( ThreadObject1 );
  }

  if(ThreadHandle1 != NULL) {
    ZwClose( ThreadHandle1 );
  }

}

Now, every ~ 100th time this function throws a bluescreen on the _ KeWaitForSingleObject( ThreadObject1, Executive, KernelMode, FALSE, NULL );_ with an Access Violation.. And I don't have a Clue why. The whole code is "guaranteed" and tested to run at IRQL = PASSIVE_LEVEL since it's running in its own thread. I checked the Thread Object's Data while I still could - it looks fine so I don't think the References had any problems. The Variables are local and not used anywhere else. So... I'm at the end of my witts. Help?

Aaron Kelbsch
Techit GmbH @ Germany

Comments

  • AaronKAaronK Member Posts: 19

    Following is the Output of !Analyze -v

    SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
    This is a very common bugcheck. Usually the exception address pinpoints
    the driver/function that caused the problem. Always note this address
    as well as the link date of the driver/image that contains this address.
    Arguments:
    Arg1: ffffffffc0000005, The exception code that was not handled
    Arg2: fffff802435c3006, The address that the exception occurred at
    Arg3: ffff858b111fe858, Exception Record Address
    Arg4: ffff858b111fe0a0, Context Record Address

    Debugging Details:

    KEY_VALUES_STRING: 1

    Key  : AV.Fault
    Value: Write
    
    Key  : Analysis.CPU.Sec
    Value: 2
    
    Key  : Analysis.DebugAnalysisProvider.CPP
    Value: Create: 8007007e on CLU-APP-9
    
    Key  : Analysis.DebugData
    Value: CreateObject
    
    Key  : Analysis.DebugModel
    Value: CreateObject
    
    Key  : Analysis.Elapsed.Sec
    Value: 2
    
    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 108
    
    Key  : Analysis.System
    Value: CreateObject
    

    BUGCHECK_CODE: 7e

    BUGCHECK_P1: ffffffffc0000005

    BUGCHECK_P2: fffff802435c3006

    BUGCHECK_P3: ffff858b111fe858

    BUGCHECK_P4: ffff858b111fe0a0

    EXCEPTION_RECORD: ffff858b111fe858 -- (.exr 0xffff858b111fe858)
    ExceptionAddress: fffff802435c3006 (nt!KeWaitForSingleObject+0x0000000000000566)
    ExceptionCode: c0000005 (Access violation)
    ExceptionFlags: 00000000
    NumberParameters: 2
    Parameter[0]: 0000000000000001
    Parameter[1]: ffffae0400000186
    Attempt to write to address ffffae0400000186

    CONTEXT: ffff858b111fe0a0 -- (.cxr 0xffff858b111fe0a0)
    rax=0000000000000000 rbx=ffff9e01fc7c0180 rcx=7224aebf251a0000
    rdx=0000000000000000 rsi=000000000000006a rdi=ffffae0400000000
    rip=fffff802435c3006 rsp=ffff858b111fea90 rbp=ffff858b111feb01
    r8=ffffae0476a68040 r9=0000000000000000 r10=7ffffffffffffffc
    r11=ffff858b111fe730 r12=0000000000000000 r13=fffff7afbfa0cfda
    r14=ffffae047c4aa080 r15=0000000000000000
    iopl=0 nv up ei pl zr na po nc
    cs=0010 ss=0000 ds=002b es=002b fs=0053 gs=002b efl=00010246
    nt!KeWaitForSingleObject+0x566:
    fffff802435c3006 889786010000 mov byte ptr [rdi+186h],dl ds:002b:ffffae0400000186=??
    Resetting default scope

    PROCESS_NAME: System

    WRITE_ADDRESS: ffffae0400000186 Nonpaged pool

    ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.
    ~~~~
    EXCEPTION_CODE_STR: c0000005

    EXCEPTION_PARAMETER1: 0000000000000001

    EXCEPTION_PARAMETER2: ffffae0400000186

    EXCEPTION_STR: 0xc0000005

    STACK_TEXT:
    ffff858b111fea90 fffff802485b2d4b : ffffae047c4aa080 0000000000000000 fffff802485ba500 0000000000000000 : nt!KeWaitForSingleObject+0x566
    ffff858b111feb60 fffff80243531bc5 : ffffae0480b59b90 fffff802485b2730 ffffae0480b59b90 0000000000000000 : LxFileMirror!CopyJobMain+0x61b
    ffff858b111fec10 fffff80243665a3c : fffff802419a7180 ffffae047e97f040 fffff80243531b70 0000000000000246 : nt!PspSystemThreadStartup+0x55
    ffff858b111fec60 0000000000000000 : ffff858b111ff000 ffff858b111f9000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x1c

    FAULTING_SOURCE_LINE: D :_Projekte\C Programmierung\MirrorTreiber_Current\FileMirror\LxFileMirror.c

    FAULTING_SOURCE_FILE: D :_Projekte\C Programmierung\MirrorTreiber_Current\FileMirror\LxFileMirror.c

    FAULTING_SOURCE_LINE_NUMBER: 1780

    FAULTING_SOURCE_CODE:
    1776: ConsoleTrace( "Set Event Durch" );
    1777:
    1778: if(ThreadObject1 != NULL) {
    1779: KeWaitForSingleObject( ThreadObject1, Executive, KernelMode, FALSE, NULL );
    1780: ObDereferenceObject( ThreadObject1 );
    1781: }
    1782: if(ThreadHandle1 != NULL) {
    1783: ZwClose( ThreadHandle1 );
    1784: }
    1785:

    SYMBOL_NAME: LxFileMirror!CopyJobMain+61b

    MODULE_NAME: LxFileMirror

    IMAGE_NAME: LxFileMirror.sys

    STACK_COMMAND: .cxr 0xffff858b111fe0a0 ; kb

    BUCKET_ID_FUNC_OFFSET: 61b

    FAILURE_BUCKET_ID: AV_LxFileMirror!CopyJobMain

    OS_VERSION: 10.0.17763.1

    BUILDLAB_STR: rs5_release

    OSPLATFORM_TYPE: x64

    OSNAME: Windows 10

    FAILURE_ID_HASH: {65838fc4-d6f9-a67c-a59d-3ec4c3de6a7b}

    Followup: MachineOwner

    Aaron Kelbsch
    Techit GmbH @ Germany

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,692

    As always happens in these cases, you have stripped out all of the interesting information.

    Here's what sticks out to me. rdi, which points to ThreadObject1, is ffffae0400000000. It is extremely suspicious that the low word is all zeros. Statistically, that just doesn't happen. My GUESS is that you are writing off the end of an array and wiping out the low-order word of ThreadObject1. So, its value is not null, but it's also not valid.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • AaronKAaronK Member Posts: 19

    Hm, sadly the ThreadStack seems to be stuck in the spam queue.
    Any other Outputs I could get for a clearer Picture?

    The code up there is pretty much all I'm doing... So no arrays no nothing. I'm just passing those variables to the functions and not doing anything with them in-between.

    I've read something about ObRefereceObjectByHandle being able to return a Positive status without actually succeeding, at least when the used handle is invalid.

    https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/failure-to-validate-object-handles

    While I'd be surprised if the handle returned by PsCreateSystemThread was invalid that's pretty much all I got.

    Is there a way to, as MSDN says "Check the object type to make sure it is what the driver expects." ?

    Aaron Kelbsch
    Techit GmbH @ Germany

  • AaronKAaronK Member Posts: 19

    Ok - Quick update. I tried to just avoid the Problem altogether by using Events.
    I got the same behavior as before. Quick documentation of what I tried.

    Analyze -v

    SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
    This is a very common bugcheck. Usually the exception address pinpoints
    the driver/function that caused the problem. Always note this address
    as well as the link date of the driver/image that contains this address.
    Arguments:
    Arg1: ffffffffc0000005, The exception code that was not handled
    Arg2: fffff8000b1b7006, The address that the exception occurred at
    Arg3: ffffc9894f5b9868, Exception Record Address
    Arg4: ffffc9894f5b90b0, Context Record Address

    Debugging Details:

    KEY_VALUES_STRING: 1

    Key  : AV.Fault
    Value: Write
    
    Key  : Analysis.CPU.Sec
    Value: 2
    
    Key  : Analysis.DebugAnalysisProvider.CPP
    Value: Create: 8007007e on CLU-APP-9
    
    Key  : Analysis.DebugData
    Value: CreateObject
    
    Key  : Analysis.DebugModel
    Value: CreateObject
    
    Key  : Analysis.Elapsed.Sec
    Value: 2
    
    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 62
    
    Key  : Analysis.System
    Value: CreateObject
    

    BUGCHECK_CODE: 7e

    BUGCHECK_P1: ffffffffc0000005

    EXCEPTION_RECORD: ffffc9894f5b9868 -- (.exr 0xffffc9894f5b9868)
    ExceptionAddress: fffff8000b1b7006 (nt!KeWaitForSingleObject+0x0000000000000566)
    ExceptionCode: c0000005 (Access violation)
    ExceptionFlags: 00000000
    NumberParameters: 2
    Parameter[0]: 0000000000000001
    Parameter[1]: ffffab8d00000186
    Attempt to write to address ffffab8d00000186

    CONTEXT: ffffc9894f5b90b0 -- (.cxr 0xffffc9894f5b90b0)
    rax=0000000000000000 rbx=ffffe6015cda8180 rcx=134ed16356510000
    rdx=0000000000000000 rsi=000000000000006a rdi=ffffab8d00000000
    rip=fffff8000b1b7006 rsp=ffffc9894f5b9aa0 rbp=ffffc9894f5b9b11
    r8=ffffab8df5e5c080 r9=0000000000000000 r10=7ffffffffffffffc
    r11=ffffc9894f5b9740 r12=0000000000000000 r13=ffffdac79e38cc81
    r14=ffffab8e03cb1d38 r15=0000000000000000
    iopl=0 nv up ei pl zr na po nc
    cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010246

    nt!KeWaitForSingleObject+0x566:
    fffff8000b1b7006 889786010000 mov byte ptr [rdi+186h],dl ds:002b:ffffab8d00000186=??
    Resetting default scope

    PROCESS_NAME: System
    WRITE_ADDRESS: ffffab8d00000186 Nonpaged pool

    STACK_TEXT:
    ffffc9894f5b9aa0 fffff8000f6a2d47 : ffffab8e03cb1d38 0000000000000000 fffff8000f6ab400 0000000000000000 : nt!KeWaitForSingleObject+0x566
    ffffc9894f5b9b70 fffff8000b125bc5 : ffffab8e03cb1c50 fffff8000f6a27b0 ffffab8e03cb1c50 0000000000000000 : LxFileMirror!CopyJobMain+0x597 [D:_Projekte\C Programmierung\MirrorTreiber_Current\FileMirror\LxFileMirror.c @ 2041]
    ffffc9894f5b9c10 fffff8000b259a3c : ffffe6015d11c180 ffffab8dfd89f080 fffff8000b125b70 0000000000000000 : nt!PspSystemThreadStartup+0x55
    ffffc9894f5b9c60 0000000000000000 : ffffc9894f5ba000 ffffc9894f5b4000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x1c

    FAULTING_SOURCE_CODE:
    2037:
    2038:
    2039: if(ThreadHandle1 != NULL) {
    2040: KeWaitForSingleObject( &PFileContext->CopyInternals.CopyBuffer[0].ThreadDone, Executive, KernelMode, FALSE, NULL );
    -- 2041: ZwClose( ThreadHandle1 );
    2042: }
    2043:
    2044: if(ThreadHandle2 != NULL) {
    2045: KeWaitForSingleObject( &PFileContext->CopyInternals.CopyBuffer[1].ThreadDone, Executive, KernelMode, FALSE, NULL );
    2046: ZwClose( ThreadHandle2 );

    ||| 0 Problem Analysis

    In routine KeWaitfor... something is trying to write to ffffab8d00000186,
    which is not Accesable or not a valid address at all.

    As you have suggested rdi is very weird.

    ffffab8d00000189 is [rdi+186h] -> rdi is ffffab8d00000000 -> my var is ffffab8e03cb1d38 so the right part seems to be lost?

    ||| 1 Checking address & content of my var --> Addres is OK, Content seems to be Ok as well.

    2: kd> ?? &PFileContext->CopyInternals.CopyBuffer[0].ThreadDone
    struct _KEVENT * 0xffffab8e03cb1d38

    LxFileMirror!KEVENT
    +0x000 Header : _DISPATCHER_HEADER
    +0x000 Lock : 0n393216
    +0x000 LockNV : 0n393216
    +0x000 Type : 0 ''
    +0x001 Signalling : 0 ''
    +0x002 Size : 0x6 ''
    +0x003 Reserved1 : 0 ''
    +0x000 TimerType : 0 ''
    +0x001 TimerControlFlags : 0 ''
    +0x001 Absolute : 0y0
    +0x001 Wake : 0y0
    +0x001 EncodedTolerableDelay : 0y000000 (0)
    +0x002 Hand : 0x6 ''
    +0x003 TimerMiscFlags : 0 ''
    +0x003 Index : 0y000000 (0)
    +0x003 Inserted : 0y0
    +0x003 Expired : 0y0
    +0x000 Timer2Type : 0 ''
    +0x001 Timer2Flags : 0 ''
    +0x001 Timer2Inserted : 0y0
    +0x001 Timer2Expiring : 0y0
    +0x001 Timer2CancelPending : 0y0
    +0x001 Timer2SetPending : 0y0
    +0x001 Timer2Running : 0y0
    +0x001 Timer2Disabled : 0y0
    +0x001 Timer2ReservedFlags : 0y00
    +0x002 Timer2ComponentId : 0x6 ''
    +0x003 Timer2RelativeId : 0 ''
    +0x000 QueueType : 0 ''
    +0x001 QueueControlFlags : 0 ''
    +0x001 Abandoned : 0y0
    +0x001 DisableIncrement : 0y0
    +0x001 QueueReservedControlFlags : 0y000000 (0)
    +0x002 QueueSize : 0x6 ''
    +0x003 QueueReserved : 0 ''
    +0x000 ThreadType : 0 ''
    +0x001 ThreadReserved : 0 ''
    +0x002 ThreadControlFlags : 0x6 ''
    +0x002 CycleProfiling : 0y0
    +0x002 CounterProfiling : 0y1
    +0x002 GroupScheduling : 0y1
    +0x002 AffinitySet : 0y0
    +0x002 Tagged : 0y0
    +0x002 EnergyProfiling : 0y0
    +0x002 SchedulerAssist : 0y0
    +0x002 ThreadReservedControlFlags : 0y0
    +0x003 DebugActive : 0 ''
    +0x003 ActiveDR7 : 0y0
    +0x003 Instrumented : 0y0
    +0x003 Minimal : 0y0
    +0x003 Reserved4 : 0y00
    +0x003 AltSyscall : 0y0
    +0x003 UmsScheduled : 0y0
    +0x003 UmsPrimary : 0y0
    +0x000 MutantType : 0 ''
    +0x001 MutantSize : 0 ''
    +0x002 DpcActive : 0x6 ''
    +0x003 MutantReserved : 0 ''
    +0x004 SignalState : 0n0
    +0x008 WaitListHead : _LIST_ENTRY [ 0xffffab8e03cb1d40 - 0xffffab8e03cb1d40 ]
    +0x000 Flink : 0xffffab8e03cb1d40
    +0x008 Blink : 0xffffab8e03cb1d40

    Aaron Kelbsch
    Techit GmbH @ Germany

  • AaronKAaronK Member Posts: 19

    ||| 2 Checking if Correct var is passed - Yes Arg1 is Correct

    ffffc9894f5b9aa0 fffff8000f6a2d47 : ffffab8e03cb1d38 0000000000000000 fffff8000f6ab400 0000000000000000 : nt!KeWaitForSingleObject+0x566

    &PFileContext->CopyInternals.CopyBuffer[0].ThreadDone = 0xffffab8e03cb1d38 = [ffffab8e03cb1d38]

    So. At least to my understanding there is nothing wrong up until now.

    ||| 3 Looking at the Thread stack

    !Thread is context

    2: kd> kP
    Child-SP RetAddr : Args to Child : Call Site
    ffffc9894f5b8088 fffff8000b32fab2 : ffffffffc0000005 0000000000000003 ffffc9894f5b81f0 fffff8000b1fa200 : nt!DbgBreakPointWithStatus
    ffffc9894f5b8090 fffff8000b32f237 : 0000000000000003 ffffc9894f5b81f0 fffff8000b266560 000000000000007e : nt!KiBugCheckDebugBreak+0x12
    ffffc9894f5b80f0 fffff8000b2526e7 : ffffc98977e65870 8bc3e05f301e817d fffff8000b44cee8 fffff8000b1c0288 : nt!KeBugCheck2+0x957
    ffffc9894f5b8810 fffff8000b26a74f : 000000000000007e ffffffffc0000005 fffff8000b1b7006 ffffc9894f5b9868 : nt!KeBugCheckEx+0x107
    ffffc9894f5b8850 fffff8000b22d41f : ffffce0a00000003 ffffc9894f5b9c10 ffffc9894f5b4000 ffffc9894f5ba000 : nt!PspSystemThreadStartup$filt$0+0x44
    ffffc9894f5b8890 fffff8000b25b0cf : ffffc9894f5b9c10 ffffc9894f5b8e70 ffffc9894f5b8f50 000000000010001f : nt!_C_specific_handler+0x9f
    ffffc9894f5b8900 fffff8000b0c5b20 : ffffc9894f5b8f50 0000000000000000 ffffc9894f5b8e70 fffff8000f6ada3c : nt!RtlpExecuteHandlerForException+0xf
    ffffc9894f5b8930 fffff8000b10ae74 : ffffc9894f5b9868 ffffc9894f5b95b0 ffffc9894f5b9868 ffffab8d00000000 : nt!RtlDispatchException+0x430
    ffffc9894f5b9080 fffff8000b263e42 : 0000000000000003 0000000000000001 0000000000000000 ffffc9894f5b9830 : nt!KiDispatchException+0x144
    ffffc9894f5b9730 fffff8000b260168 : 0000000000000000 0000000000000001 0000000000000001 ffffab8dfd89f080 : nt!KiExceptionDispatch+0xc2
    ffffc9894f5b9910 fffff8000b1b7006 : 0000000000000000 fffff80000000000 ffffab8e00000000 ffffc9894f5b9b11 : nt!KiPageFault+0x428 (TrapFrame @ ffffc9894f5b9910) ffffc9894f5b9aa0 fffff8000f6a2d47 : ffffab8e03cb1d38 0000000000000000 fffff8000f6ab400 0000000000000000 : nt!KeWaitForSingleObject+0x566 ffffc9894f5b9b70 fffff8000b125bc5 : ffffab8e03cb1c50 fffff8000f6a27b0 ffffab8e03cb1c50 0000000000000000 : LxFileMirror!CopyJobMain+0x597 [D:\_Projekte\C Programmierung\MirrorTreiber\_Current\FileMirror\LxFileMirror.c @ 2041] ffffc9894f5b9c10 fffff8000b259a3c : ffffe6015d11c180 ffffab8dfd89f080 fffff8000b125b70 0000000000000000 : nt!PspSystemThreadStartup+0x55 ffffc9894f5b9c60 0000000000000000 : ffffc9894f5ba000 ffffc9894f5b4000 0000000000000000 00000000`00000000 : nt!KiStartSystemThread+0x1c

    trap is context
    2: kd> .trap ffffc989`4f5b9910

    NOTE: The trap frame does not contain all registers.
    Some register values may be zeroed or incorrect.
    rax=0000000000000000 rbx=0000000000000000 rcx=134ed16356510000
    rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
    rip=fffff8000b1b7006 rsp=ffffc9894f5b9aa0 rbp=ffffc9894f5b9b11
    r8=ffffab8df5e5c080 r9=0000000000000000 r10=7ffffffffffffffc
    r11=ffffc9894f5b9740 r12=0000000000000000 r13=0000000000000000
    r14=0000000000000000 r15=0000000000000000
    iopl=0 nv up ei pl zr na po nc
    nt!KeWaitForSingleObject+0x566:
    fffff8000b1b7006 889786010000 mov byte ptr [rdi+186h],dl ds:0000000000000186=??

    Child-SP RetAddr : Args to Child : Call Site
    ffffc9894f5b9aa0 fffff8000f6a2d47 : ffffab8e03cb1d38 0000000000000000 fffff8000f6ab400 0000000000000000 : nt!KeWaitForSingleObject+0x566
    ffffc9894f5b9b70 fffff8000b125bc5 : ffffab8e03cb1c50 fffff8000f6a27b0 ffffab8e03cb1c50 0000000000000000 : LxFileMirror!CopyJobMain+0x597 [D:_Projekte\C Programmierung\MirrorTreiber_Current\FileMirror\LxFileMirror.c @ 2041]
    ffffc9894f5b9c10 fffff8000b259a3c : ffffe6015d11c180 ffffab8dfd89f080 fffff8000b125b70 0000000000000000 : nt!PspSystemThreadStartup+0x55
    ffffc9894f5b9c60 0000000000000000 : ffffc9894f5ba000 ffffc9894f5b4000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x1c

    I dont really get the PageFault there... Is it caused by the incorrect RDI or?

    ||| 4 Other things I checked

    My DbgPrint suggests that
    1. IRQl was PASSIVE_LEVEL when the KeWaitForSingleObject was called
    2. The AccesViolation was caused after the Event was signaled.

       |  Trace  | [IRQ 0] Set Event Done -> WaitFor is called after this log
       |  Trace  | [IRQ 0] [ Stop ] CopyJobWrite  Status 0x0 -> Event is Set after this one
       Then BSOD
    

    The IRQL when the exception occured seems to have been DISPATCH_LEVEL
    2: kd> !irql
    Debugger saved IRQL for processor 0x2 -- 2 (DISPATCH_LEVEL)

    Aaron Kelbsch
    Techit GmbH @ Germany

  • AaronKAaronK Member Posts: 19

    Well, the part of my message was flagged as spam. I just said that I changed my approach to use normal Events.
    Which lead to the same behavior. I repeated the Info in the spoiler below

    SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
    This is a very common bugcheck. Usually the exception address pinpoints
    the driver/function that caused the problem. Always note this address
    as well as the link date of the driver/image that contains this address.
    Arguments:
    Arg1: ffffffffc0000005, The exception code that was not handled
    Arg2: fffff8000b1b7006, The address that the exception occurred at
    Arg3: ffffc9894f5b9868, Exception Record Address
    Arg4: ffffc9894f5b90b0, Context Record Address

    Debugging Details:

    KEY_VALUES_STRING: 1

    Key  : AV.Fault
    Value: Write
    
    Key  : Analysis.CPU.Sec
    Value: 2
    
    Key  : Analysis.DebugAnalysisProvider.CPP
    Value: Create: 8007007e on CLU-APP-9
    
    Key  : Analysis.DebugData
    Value: CreateObject
    
    Key  : Analysis.DebugModel
    Value: CreateObject
    
    Key  : Analysis.Elapsed.Sec
    Value: 2
    
    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 62
    
    Key  : Analysis.System
    Value: CreateObject
    

    BUGCHECK_CODE: 7e

    BUGCHECK_P1: ffffffffc0000005

    EXCEPTION_RECORD: ffffc9894f5b9868 -- (.exr 0xffffc9894f5b9868)
    ExceptionAddress: fffff8000b1b7006 (nt!KeWaitForSingleObject+0x0000000000000566)
    ExceptionCode: c0000005 (Access violation)
    ExceptionFlags: 00000000
    NumberParameters: 2
    Parameter[0]: 0000000000000001
    Parameter[1]: ffffab8d00000186
    Attempt to write to address ffffab8d00000186

    CONTEXT: ffffc9894f5b90b0 -- (.cxr 0xffffc9894f5b90b0)
    rax=0000000000000000 rbx=ffffe6015cda8180 rcx=134ed16356510000
    rdx=0000000000000000 rsi=000000000000006a rdi=ffffab8d00000000
    rip=fffff8000b1b7006 rsp=ffffc9894f5b9aa0 rbp=ffffc9894f5b9b11
    r8=ffffab8df5e5c080 r9=0000000000000000 r10=7ffffffffffffffc
    r11=ffffc9894f5b9740 r12=0000000000000000 r13=ffffdac79e38cc81
    r14=ffffab8e03cb1d38 r15=0000000000000000
    iopl=0 nv up ei pl zr na po nc
    cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010246

    nt!KeWaitForSingleObject+0x566:
    fffff8000b1b7006 889786010000 mov byte ptr [rdi+186h],dl ds:002b:ffffab8d00000186=??
    Resetting default scope

    PROCESS_NAME: System
    WRITE_ADDRESS: ffffab8d00000186 Nonpaged pool

    STACK_TEXT:
    ffffc9894f5b9aa0 fffff8000f6a2d47 : ffffab8e03cb1d38 0000000000000000 fffff8000f6ab400 0000000000000000 : nt!KeWaitForSingleObject+0x566
    ffffc9894f5b9b70 fffff8000b125bc5 : ffffab8e03cb1c50 fffff8000f6a27b0 ffffab8e03cb1c50 0000000000000000 : LxFileMirror!CopyJobMain+0x597 [D:_Projekte\C Programmierung\MirrorTreiber_Current\FileMirror\LxFileMirror.c @ 2041]
    ffffc9894f5b9c10 fffff8000b259a3c : ffffe6015d11c180 ffffab8dfd89f080 fffff8000b125b70 0000000000000000 : nt!PspSystemThreadStartup+0x55
    ffffc9894f5b9c60 0000000000000000 : ffffc9894f5ba000 ffffc9894f5b4000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x1c

    FAULTING_SOURCE_CODE:
    2037:
    2038:
    2039: if(ThreadHandle1 != NULL) {
    2040: KeWaitForSingleObject( &PFileContext->CopyInternals.CopyBuffer[0].ThreadDone, Executive, KernelMode, FALSE, NULL );
    -- 2041: ZwClose( ThreadHandle1 );
    2042: }
    2043:
    2044: if(ThreadHandle2 != NULL) {
    2045: KeWaitForSingleObject( &PFileContext->CopyInternals.CopyBuffer[1].ThreadDone, Executive, KernelMode, FALSE, NULL );
    2046: ZwClose( ThreadHandle2 );

    ||| 0 Problem Analysis

    In routine KeWaitfor... something is trying to write to ffffab8d00000186,
    which is not Accesable or not a valid address at all.

    As you have suggested rdi is very weird.

    ffffab8d00000189 is [rdi+186h] -> rdi is ffffab8d00000000 -> my var is ffffab8e03cb1d38 so the right part seems to be lost?

    ||| 1 Checking address & content of my var --> Addres is OK, Content seems to be Ok as well.

    2: kd> ?? &PFileContext->CopyInternals.CopyBuffer[0].ThreadDone
    struct _KEVENT * 0xffffab8e03cb1d38

    LxFileMirror!KEVENT
    +0x000 Header : _DISPATCHER_HEADER
    +0x000 Lock : 0n393216
    +0x000 LockNV : 0n393216
    +0x000 Type : 0 ''
    +0x001 Signalling : 0 ''
    +0x002 Size : 0x6 ''
    +0x003 Reserved1 : 0 ''
    +0x000 TimerType : 0 ''
    +0x001 TimerControlFlags : 0 ''
    +0x001 Absolute : 0y0
    +0x001 Wake : 0y0
    +0x001 EncodedTolerableDelay : 0y000000 (0)
    +0x002 Hand : 0x6 ''
    +0x003 TimerMiscFlags : 0 ''
    +0x003 Index : 0y000000 (0)
    +0x003 Inserted : 0y0
    +0x003 Expired : 0y0
    +0x000 Timer2Type : 0 ''
    +0x001 Timer2Flags : 0 ''
    +0x001 Timer2Inserted : 0y0
    +0x001 Timer2Expiring : 0y0
    +0x001 Timer2CancelPending : 0y0
    +0x001 Timer2SetPending : 0y0
    +0x001 Timer2Running : 0y0
    +0x001 Timer2Disabled : 0y0
    +0x001 Timer2ReservedFlags : 0y00
    +0x002 Timer2ComponentId : 0x6 ''
    +0x003 Timer2RelativeId : 0 ''
    +0x000 QueueType : 0 ''
    +0x001 QueueControlFlags : 0 ''
    +0x001 Abandoned : 0y0
    +0x001 DisableIncrement : 0y0
    +0x001 QueueReservedControlFlags : 0y000000 (0)
    +0x002 QueueSize : 0x6 ''
    +0x003 QueueReserved : 0 ''
    +0x000 ThreadType : 0 ''
    +0x001 ThreadReserved : 0 ''
    +0x002 ThreadControlFlags : 0x6 ''
    +0x002 CycleProfiling : 0y0
    +0x002 CounterProfiling : 0y1
    +0x002 GroupScheduling : 0y1
    +0x002 AffinitySet : 0y0
    +0x002 Tagged : 0y0
    +0x002 EnergyProfiling : 0y0
    +0x002 SchedulerAssist : 0y0
    +0x002 ThreadReservedControlFlags : 0y0
    +0x003 DebugActive : 0 ''
    +0x003 ActiveDR7 : 0y0
    +0x003 Instrumented : 0y0
    +0x003 Minimal : 0y0
    +0x003 Reserved4 : 0y00
    +0x003 AltSyscall : 0y0
    +0x003 UmsScheduled : 0y0
    +0x003 UmsPrimary : 0y0
    +0x000 MutantType : 0 ''
    +0x001 MutantSize : 0 ''
    +0x002 DpcActive : 0x6 ''
    +0x003 MutantReserved : 0 ''
    +0x004 SignalState : 0n0
    +0x008 WaitListHead : _LIST_ENTRY [ 0xffffab8e03cb1d40 - 0xffffab8e03cb1d40 ]
    +0x000 Flink : 0xffffab8e03cb1d40
    +0x008 Blink : 0xffffab8e03cb1d40

    Aaron Kelbsch
    Techit GmbH @ Germany

  • AaronKAaronK Member Posts: 19

    Well, last info.

    I bypassed the problem with polling for now . Not great but works.

    Aaron Kelbsch
    Techit GmbH @ Germany

  • AaronKAaronK Member Posts: 19

    Ok. So - after bypassing this problem I have the exact same behavior in a completely different part of my Program. Once again at random every X times in my stress test.

    This time it's while calling FltDeleteContext(). The lower word of one of the Registers (rbx) once again is all Zeroes which leads to another AccesViolation.

    The FltDeleteContext is being called from it's own Thread which was created when the Context was created. (Coul)

        InitializeObjectAttributes( &ObjectAttributes, NULL, OBJ_INHERIT | OBJ_KERNEL_HANDLE, NULL, NULL );
        Status = PsCreateSystemThread( &Thread, THREAD_ALL_ACCESS, &ObjectAttributes, NULL, NULL, WaitForRevSemZeroThread, Context );
    

    CONTEXT: ffffe90b2998e0d0 -- (.cxr 0xffffe90b2998e0d0)
    rax=0000000000000000 rbx=ffff800800000000 rcx=b47e3950162c0000
    rdx=0000000000000039 rsi=ffff8008a8632df0 rdi=ffff8008a20f6820
    rip=fffff80af7ed2e03 rsp=ffffe90b2998eac0 rbp=0000000000000000
    r8=0000000000000065 r9=0000000000000002 r10=ffffe90b2998e1f0
    r11=0000000000000000 r12=0000000000000606 r13=ffff8008a0e1e740
    r14=0000000000000000 r15=0000000000000000

    The Context Pointer being passed into the Function is fine.

    My Variable = struct _FILEMIRROR_FILE_CONTEXT * 0xffff8008`a20f6880

    Stack trace Trap:

    ffffe90b2998eac0 fffff80af7ed1652 : 0000000000000080 ffff8008a7dfae20 ffff8008a20f6820 ffff8008a20f6820 : FLTMGR!DoReleaseContext+0x83
    ffffe90b2998eb00 fffff80af7f2dc4a : ffff8008a20f6880 0000000000000080 ffff8008a20f68c8 ffffe90b2998ebc0 : FLTMGR!FltDeleteContext+0xe2
    ffffe90b2998eb30 fffff80244e092d4 : 0000000000000080 fffff802469fc200 fffff80244e09e40 0000000000000000 : FLTMGR!FltvDeleteContext+0x3a
    ffffe90b2998eb60 fffff80244e08bf2 : ffff8008a20f6880 fffff80244e0c170 0000000000000000 0000000000000000 : LxFileMirror!_DbgDeleteContext+0xe4
    ffffe90b2998ebe0 fffff80246927bc5 : ffff8008a20f6880 fffff80244e08ba0 ffff8008a20f6880 0000000000000000 : LxFileMirror!WaitForRevSemZeroThread+0x52
    ffffe90b2998ec10 fffff80246a5ba3c : ffffc500739c0180 ffff8008a1d7c0c0 fffff80246927b70 0000000000000000 : nt!PspSystemThreadStartup+0x55
    ffffe90b2998ec60 0000000000000000 : ffffe90b2998f000 ffffe90b29989000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x1c

    Stack trace Thread:

    THREAD ffff8008a1d7c0c0 Cid 0004.13f8 Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor 1
    Not impersonating
    DeviceMap ffff9f0a05813a20
    Owning Process ffff80089d48f280 Image: System
    Attached Process N/A Image: N/A
    Wait Start TickCount 2353885 Ticks: 2 (0:00:00:00.031)
    Context Switch Count 19 IdealProcessor: 1
    UserTime 00:00:00.000
    KernelTime 00:00:00.031
    Win32 Start Address LxFileMirror!WaitForRevSemZeroThread (0xfffff80244e08ba0)
    Stack Init ffffe90b2998ec90 Current ffffe90b2998d420
    Base ffffe90b2998f000 Limit ffffe90b29989000 Call 0000000000000000
    Priority 8 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
    Child-SP RetAddr : Args to Child : Call Site
    ffffe90b2998d0a8 fffff80246b31ab2 : ffffffffc0000005 0000000000000003 ffffe90b2998d210 fffff802469fc200 : nt!DbgBreakPointWithStatus
    ffffe90b2998d0b0 fffff80246b31237 : 0000000000000003 ffffe90b2998d210 fffff80246a68560 000000000000007e : nt!KiBugCheckDebugBreak+0x12
    ffffe90b2998d110 fffff80246a546e7 : 0000000000000000 0000000000000000 fffff80246c4eee8 fffff802469c2288 : nt!KeBugCheck2+0x957
    ffffe90b2998d830 fffff80246a6c74f : 000000000000007e ffffffffc0000005 fffff80af7ed2e03 ffffe90b2998e888 : nt!KeBugCheckEx+0x107
    ffffe90b2998d870 fffff80246a2f41f : 0000029700000003 ffffe90b2998ec10 ffffe90b29989000 ffffe90b2998f000 : nt!PspSystemThreadStartup$filt$0+0x44
    ffffe90b2998d8b0 fffff80246a5d0cf : ffffe90b2998ec10 ffffe90b2998de90 ffffe90b2998df70 000000000010001f : nt!_C_specific_handler+0x9f
    ffffe90b2998d920 fffff802468c7b20 : ffffe90b2998df70 0000000000000000 ffffe90b2998de90 fffff80244e0d928 : nt!RtlpExecuteHandlerForException+0xf
    ffffe90b2998d950 fffff8024690ce74 : ffffe90b2998e888 ffffe90b2998e5d0 ffffe90b2998e888 ffff8008a20f6820 : nt!RtlDispatchException+0x430
    ffffe90b2998e0a0 fffff80246a65e42 : ffff57c720c037c0 0000000000000000 0000000000001000 ffffe90b2998e930 : nt!KiDispatchException+0x144
    ffffe90b2998e750 fffff80246a62168 : 0000000000000000 0000000000000000 0000000000000606 0000000000000000 : nt!KiExceptionDispatch+0xc2
    ffffe90b2998e930 fffff80af7ed2e03 : ffff8008a20f6880 ffff8008a7df0004 0000000000000000 0000000000000606 : nt!KiPageFault+0x428 (TrapFrame @ ffffe90b2998e930)
    ffffe90b2998eac0 fffff80af7ed1652 : 0000000000000080 ffff8008a7dfae20 ffff8008a20f6820 ffff8008a20f6820 : FLTMGR!DoReleaseContext+0x83
    ffffe90b2998eb00 fffff80af7f2dc4a : ffff8008a20f6880 0000000000000080 ffff8008a20f68c8 ffffe90b2998ebc0 : FLTMGR!FltDeleteContext+0xe2
    ffffe90b2998eb30 fffff80244e092d4 : 0000000000000080 fffff802469fc200 fffff80244e09e40 0000000000000000 : FLTMGR!FltvDeleteContext+0x3a
    ffffe90b2998eb60 fffff80244e08bf2 : ffff8008a20f6880 fffff80244e0c170 0000000000000000 0000000000000000 : LxFileMirror!_DbgDeleteContext+0xe4
    ffffe90b2998ebe0 fffff80246927bc5 : ffff8008a20f6880 fffff80244e08ba0 ffff8008a20f6880 0000000000000000 : LxFileMirror!WaitForRevSemZeroThread+0x52
    ffffe90b2998ec10 fffff80246a5ba3c : ffffc500739c0180 ffff8008a1d7c0c0 fffff80246927b70 0000000000000000 : nt!PspSystemThreadStartup+0x55
    ffffe90b2998ec60 0000000000000000 : ffffe90b2998f000 ffffe90b29989000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x1c

    What could be the cause of this?

    Aaron Kelbsch
    Techit GmbH @ Germany

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,362

    Double free of the context? Or pool corruption elsewhere.

    Try enabling Verifier on both your driver and FltMgr.sys.

    -scott
    OSR

  • AaronKAaronK Member Posts: 19

    Hi Scott,

    Thank you for your reply.

    The Verifier on both Drivers is not a bad Idea, I had it enabled for my Driver only.

    About the Double free - I keep my own reference counter inside the Context.
    Unless after flagging the Context for deletion, then decreasing the Ref to 0 it was still possible for something to reference the context (Which I now check as well) there should be no way for it to get freed twice without an Assertion.

    What could cause a Pool corruption to happen?

    I've also had a few KERNEL_SECURITY_CHECK_FAILURE with an overrun Stack buffer BSODs as well.
    Sadly I never found the reason for this. If the Stack is correct it`s also caused by freeing the buffer.

    I had a short trace of this left in my notepad - Maybe you see something I dont.

    nt!DbgBreakPointWithStatus:
    fffff8071b280970 cc int 3
    3: kd> !analyze -v


    KERNEL_SECURITY_CHECK_FAILURE (139)
    A kernel component has corrupted a critical data structure. The corruption
    could potentially allow a malicious user to gain control of this machine.
    Arguments:
    Arg1: 0000000000000000, A stack-based buffer has been overrun.
    Arg2: 0000000000000000, Address of the trap frame for the exception that caused the bugcheck
    Arg3: 0000000000000000, Address of the exception record for the exception that caused the bugcheck
    Arg4: 0000000000000089, Reserved

    TRAP_FRAME: ffff800000000000 -- (.trap 0xffff800000000000)
    Unable to read trap frame at ffff800000000000

    EXCEPTION_RECORD: 0000000000000000 -- (.exr 0x0)
    Cannot read Exception record @ 0000000000000000

    3: kd> !thread
    THREAD ffff8b8eba7036c0 Cid 0f68.112c Teb: 0000002cf0fc3000 Win32Thread: 0000000000000000 RUNNING on processor 3
    IRP List:
    ffff8b8eb678eb80: (0006,0478) Flags: 40000884 Mdl: 00000000
    ffff8b8ebcc70ea0: (0006,0160) Flags: 40000884 Mdl: 00000000
    ffff8b8ebc4e4e10: (0006,01f0) Flags: 40000884 Mdl: 00000000
    Impersonation token: ffffde87feb1a060 (Level Impersonation)
    DeviceMap ffffde87fee0e530
    Owning Process ffff8b8eba6d9080 Image: vmwp.exe
    Attached Process N/A Image: N/A
    Wait Start TickCount 2039345 Ticks: 0
    Context Switch Count 14 IdealProcessor: 3
    UserTime 00:00:00.000
    KernelTime 00:00:00.031
    Win32 Start Address ntdll!TppWorkerThread (0x00007ffe53413ce0)
    Stack Init ffff9d88bd06fc90 Current ffff9d88bd06ccb0
    Base ffff9d88bd070000 Limit ffff9d88bd06a000 Call 0000000000000000
    Priority 9 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
    Child-SP RetAddr : Args to Child : Call Site
    ffff9d88bd06b668 fffff8071b35ddc2 : 0000000000000000 0000000000000003 ffff9d88bd06b7d0 fffff8071b1db4d0 : nt!DbgBreakPointWithStatus
    ffff9d88bd06b670 fffff8071b35d4b7 : 0000000000000003 ffff9d88bd06b7d0 fffff8071b28d1a0 0000000000000139 : nt!KiBugCheckDebugBreak+0x12
    ffff9d88bd06b6d0 fffff8071b278c27 : 0000000000000000 0000000000000001 ffff9d88bd06d080 0000000000000000 : nt!KeBugCheck2+0x947
    ffff9d88bd06bdd0 fffff8071b28155b : 0000000000000139 0000000000000000 0000000000000000 0000000000000000 : nt!KeBugCheckEx+0x107
    ffff9d88bd06be10 fffff8071b174e81 : 0000000000000000 0000000000000002 0000000000000000 0000000000000000 : nt!guard_icall_bugcheck+0x1b
    ffff9d88bd06be40 fffff8071b253775 : 0000000000000000 ffff9d88bd06d810 fffff8071aa8b4bc ffff9d88bd06c460 : nt!KeCheckStackAndTargetAddress+0x51
    ffff9d88bd06be70 fffff8071b28190f : ffff9d88bd06d810 ffff9d88bd06c450 0000000000000000 000000000010001f : nt!_C_specific_handler+0x45
    ffff9d88bd06bee0 fffff8071b0cc885 : 0000000000000000 0000000000000000 ffff9d88bd06c450 00007fffffff0000 : nt!RtlpExecuteHandlerForException+0xf
    ffff9d88bd06bf10 fffff8071b0caf1e : ffff9d88bd06ce48 ffff9d88bd06cb90 ffff9d88bd06ce48 a2e64eada2e64ead : nt!RtlDispatchException+0x4a5
    ffff9d88bd06c660 fffff8071b28aa5d : ffffeef77bbdd000 ffff9d88bd06cef0 ffff800000000000 0000000000000089 : nt!KiDispatchException+0x16e
    ffff9d88bd06cd10 fffff8071b286c43 : 0000000000000002 0000000000000000 ffff800000000000 fffff8071b0d3a9a : nt!KiExceptionDispatch+0x11d
    ffff9d88bd06cef0 0000000000000089 : ffff8b8eaf130000 0000000062736c61 ffff8b8ebc56cdd0 a2e64eada2e64ead : nt!KiPageFault+0x443 (TrapFrame @ ffff9d88bd06cef0)
    ffff9d88bd06d080 ffff8b8eaf130000 : 0000000062736c61 ffff8b8ebc56cdd0 a2e64eada2e64ead 0000000000000002 : 0x89
    ffff9d88bd06d088 0000000062736c61 : ffff8b8ebc56cdd0 a2e64eada2e64ead 0000000000000002 0000000046465355 : 0xffff8b8eaf130000
    ffff9d88bd06d090 ffff8b8ebc56cdd0 : a2e64eada2e64ead 0000000000000002 0000000046465355 ffffde880508ed70 : 0x62736c61
    ffff9d88bd06d098 a2e64eada2e64ead : 0000000000000002 0000000046465355 ffffde880508ed70 fffff8071aabf463 : 0xffff8b8ebc56cdd0
    ffff9d88bd06d0a0 0000000000000002 : 0000000046465355 ffffde880508ed70 fffff8071aabf463 0000000000000103 : 0xa2e64eada2e64ead
    ffff9d88bd06d0a8 0000000046465355 : ffffde880508ed70 fffff8071aabf463 0000000000000103 0000000000000000 : 0x2
    ffff9d88bd06d0b0 ffffde880508ed70 : fffff8071aabf463 0000000000000103 0000000000000000 ffff9d88bd06d1f0 : 0x46465355
    ffff9d88bd06d0b8 fffff8071aabf463 : 0000000000000103 0000000000000000 ffff9d88bd06d1f0 ffff9d88bd06d2d8 : 0xffffde880508ed70
    ffff9d88bd06d0c0 fffff80719fa3688 : 0000000040011001 ffff8b8e00000000 fffff80719fa0002 ffff9d88bd060001 : FLTMGR!FltvReleaseContext+0x23
    ffff9d88bd06d0f0 fffff80719fa2788 : ffffde880508ed70 ffff8b8eb8eeb730 ffff8b8eb81cf010 ffff8b8e00000000 : LxFileMirror!InitializeFileContext+0x804 [D:_Projekte\C Programmierung\MirrorTreiber_Current\FileMirror\LxFileMirror.c @ 1779]
    ffff9d88bd06d250 fffff80719fa114b : ffff9d88bd06d4d0 ffff8b8eb81cf016 ffff9d88bd06d4d0 ffff8b8eb2d05b01 : LxFileMirror!GetMCFGandContinue+0x29c [D:_Projekte\C Programmierung\MirrorTreiber_Current\FileMirror\LxFileMirror.c @ 1572]
    ffff9d88bd06d380 fffff8071aabec95 : ffffde880508ed70 ffff8b8eb2d05b28 0000000000000000 0000000000000000 : LxFileMirror!FileMirrorAfterOpen+0x11b [D:_Projekte\C Programmierung\MirrorTreiber_Current\FileMirror\LxFileMirror.c @ 1134]
    ffff9d88bd06d3f0 fffff8071aa62c33 : 0000000000000000 0000000000000000 0000000000000000 fffff80700000000 : FLTMGR!FltvPostOperation+0xb5
    ffff9d88bd06d480 fffff8071aa62438 : ffff8b8e00000000 0000000000000000 ffff8b8ebd80ce10 0000000000000000 : FLTMGR!FltpPerformPostCallbacks+0x3e3
    ffff9d88bd06d550 fffff8071aa646b0 : 0000000000000000 fffff8071aa7b470 0000000000000008 ffff8b8eb2d05a40 : FLTMGR!FltpPassThroughCompletionWorker+0x128
    ffff9d88bd06d5d0 fffff8071aa9bd27 : ffff9d88bd06d690 fffff8071ba22a0a 0000000000000000 0000000000000000 : FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x200
    ffff9d88bd06d650 fffff8071b2357ba : 0000000000000000 ffff8b8eb678eb80 0000000000000000 0000000000000000 : FLTMGR!FltpCreate+0x307
    ffff9d88bd06d700 fffff8071ba180a9 : ffff8b8eb678eb80 ffff8b8eb26a3b60 ffff8b8e00000010 ffff9d88bd06d788 : nt!IopfCallDriver+0x56
    ffff9d88bd06d740 fffff8071b2aaa27 : 0000000000000005 ffff9d88bd06da80 ffff8b8eb2afe3a0 ffff8b8ec9202470 : nt!IovCallDriver+0x275
    ffff9d88bd06d780 fffff8071b1bf404 : 0000000000000003 0000000000000000 0000000000000001 fffff8071b1db746 : nt!IofCallDriver+0x1be927
    ffff9d88bd06d7c0 fffff8071b6b60be : ffff9d88bd06da80 0000000000000005 ffff8b8eb2afe3a0 ffff8b8eb678ef68 : nt!IoCallDriverWithTracing+0x34
    ffff9d88bd06d810 fffff8071b6ab66f : ffff8b8eb268eb80 ffff8b8eb268eb05 ffff8b8eb9ef1660 0000000000000000 : nt!IopParseDevice+0x121e
    ffff9d88bd06d980 fffff8071b6a9ad1 : ffff8b8eb9ef1600 ffff9d88bd06dbc8 ffff8b8e00000240 ffff8b8eb00f9c40 : nt!ObpLookupObjectName+0x78f
    ffff9d88bd06db40 fffff8071b6cc7a6 : 0000000000000001 ffff9d88bd06de60 0000000000000000 ffffa2015c125180 : nt!ObOpenObjectByNameEx+0x201
    ffff9d88bd06dc80 fffff8071b6cc06d : ffff9d88bd06de40 00000000c0100000 ffff9d88bd06de60 ffff9d88bd06de50 : nt!IopCreateFile+0x606
    ffff9d88bd06dd20 fffff80719eaa85e : ffff8b8eba8f1048 ffff9d88bd06dec0 00000000c0100000 0000000000000000 : nt!IoCreateFileEx+0x11d
    ffff9d88bd06ddc0 fffff80719ebd6a7 : ffff9d88bd06df78 fffff80719ec6345 ffff8b8eba8f1401 0000000000000000 : vhdmp!VhdmpiOpenBackingFileWithOptions+0x172
    ffff9d88bd06df80 fffff80719ebdcc1 : 0000000000000000 0000000000000000 ffff9d8800000001 ffff8b8eba8f1048 : vhdmp!VhdmpiOpenBackingFile+0xa3

    3: kd> r
    rax=0000000000000000 rbx=0000000000000003 rcx=0000000000000003
    rdx=000000000000008a rsi=0000000000000000 rdi=ffffa2015c125180
    rip=fffff8071b280970 rsp=ffff9d88bd06b668 rbp=ffff9d88bd06b7d0
    r8=0000000000000065 r9=0000000000000000 r10=0000000000000000
    r11=ffff9d88bd06b490 r12=0000000000000003 r13=0000000000000000
    r14=0000000000000000 r15=ffff8b8eba7036c0
    iopl=0 nv up ei ng nz na pe nc
    cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00040282
    nt!DbgBreakPointWithStatus:
    fffff8071b280970 cc int 3

    Aaron Kelbsch
    Techit GmbH @ Germany

  • AaronKAaronK Member Posts: 19

    So, Quick update.

    Enabling the Verifier for both driver ended in instant Bluescreens for some reason.

    Now - I retried the whole thing with some different settings (on only my own driver) and now I got this trace.

    SYSTEM_SERVICE_EXCEPTION (3b)
    An exception happened while executing a system service routine.
    Arguments:
    Arg1: 00000000c0000005, Exception code that caused the bugcheck
    Arg2: fffff8025780fdc9, Address of the instruction which caused the bugcheck
    Arg3: ffffa28a74e50a00, Address of the context record for the exception that caused the bugcheck
    Arg4: 0000000000000000, zero.

    Debugging Details:

    CONTEXT: ffffa28a74e50a00 -- (.cxr 0xffffa28a74e50a00)
    rax=0000000000000000 rbx=ffffcc0c00000000 rcx=0000000000000000
    rdx=ffffcc0ce8c952e0 rsi=0000000000000000 rdi=ffffa28a74e514d0
    rip=fffff8025780fdc9 rsp=ffffa28a74e513f0 rbp=ffffcc0cd7ecc010
    r8=ffffcc0ce8c952e0 r9=ffffcc0ce8c90600 r10=ffffcc0cd7ecc390
    r11=ffffcc0ce8c90b40 r12=ffffcc0cd4b0f701 r13=ffffcc0cd78bce00
    r14=0000000000000036 r15=0000000000000001
    iopl=0 nv up ei pl zr na po nc
    cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00050246
    FLTMGR!FltvPostOperation+0x1e9:
    fffff8025780fdc9 488b4310 mov rax,qword ptr [rbx+10h] ds:002b:ffffcc0c00000010=????????????????
    Resetting default scope

    PROCESS_NAME: vmwp.exe

    STACK_TEXT:
    ffffa28a74e513f0 fffff802577b3c33 : 0000000000000000 0000000000000000 0000000000000000 fffff80200000000 : FLTMGR!FltvPostOperation+0x1e9
    ffffa28a74e51480 fffff802577b3438 : ffffcc0c00000000 0000000000000000 ffffcc0cdbe5de90 0000000000000000 : FLTMGR!FltpPerformPostCallbacks+0x3e3
    ffffa28a74e51550 fffff802577b56b0 : 0000000000000000 fffff802577cc470 0000000000000008 ffffcc0cd4b0f660 : FLTMGR!FltpPassThroughCompletionWorker+0x128
    ffffa28a74e515d0 fffff802577ecd27 : ffffa28a74e51690 fffff80258830a0a 0000000000000000 0000000000000000 : FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x200
    ffffa28a74e51650 fffff802580437ba : 0000000000000000 ffffcc0cda3cab80 0000000000000000 0000000000000000 : FLTMGR!FltpCreate+0x307
    ffffa28a74e51700 fffff802588260a9 : ffffcc0cda3cab80 ffffcc0cd1f3ede0 ffffcc0c00000010 ffffa28a74e51788 : nt!IopfCallDriver+0x56
    ffffa28a74e51740 fffff802580b8a27 : 0000000000000005 ffffa28a74e51a80 ffffcc0cd1f2a800 ffffcc0cd4503840 : nt!IovCallDriver+0x275
    ffffa28a74e51780 fffff80257fcd404 : 0000000000000003 0000000000000000 0000000000000001 fffff80257fe9746 : nt!IofCallDriver+0x1be927
    ffffa28a74e517c0 fffff802584c40be : ffffa28a74e51a80 0000000000000005 ffffcc0cd1f2a800 ffffcc0cda3caf68 : nt!IoCallDriverWithTracing+0x34
    ffffa28a74e51810 fffff802584b966f : ffffcc0cd1a92b80 ffffcc0cd1a92b05 ffffcc0cd8949010 0000000000000000 : nt!IopParseDevice+0x121e
    ffffa28a74e51980 fffff802584b7ad1 : ffffcc0cd8949000 ffffa28a74e51bc8 ffffcc0c00000240 ffffcc0ccf4f97a0 : nt!ObpLookupObjectName+0x78f
    ffffa28a74e51b40 fffff802584da7a6 : 0000000000000001 ffffa28a74e51e60 0000000000000000 ffff88817a5e5180 : nt!ObOpenObjectByNameEx+0x201
    ffffa28a74e51c80 fffff802584da06d : ffffa28a74e51e40 00000000c0100000 ffffa28a74e51e60 ffffa28a74e51e50 : nt!IopCreateFile+0x606
    ffffa28a74e51d20 fffff8025b0ca85e : ffffcc0cd9cb4048 ffffa28a74e51ec0 00000000c0100000 0000000000000000 : nt!IoCreateFileEx+0x11d
    ffffa28a74e51dc0 fffff8025b0dd6a7 : ffffa28a74e51f78 fffff8025b0e6345 ffffcc0cd9cb4401 0000000000000000 : vhdmp!VhdmpiOpenBackingFileWithOptions+0x172
    ffffa28a74e51f80 fffff8025b0ddcc1 : 0000000000000000 0000000000000000 ffffa28a00000001 ffffcc0cd9cb4048 : vhdmp!VhdmpiOpenBackingFile+0xa3
    ffffa28a74e52050 fffff8025b0de866 : ffffcc0cd9cb4048 0000000000000002 ffffcc0cd9cb4280 fffff8025b0ca471 : vhdmp!VhdmpiOpenFileWrapperExclusiveHandle+0x89
    ffffa28a74e520d0 fffff8025b0dc92e : ffffcc0cd9cb4000 ffffcc0cd9cb4048 0000000000000100 ffffcc0cd9cb4280 : vhdmp!VhdmpiUpgradeFileWrapperToWX+0x9a
    ... shortened for char limit ...
    000000f5320ffe80 00007ff860cad4d1 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : KERNEL32!BaseThreadInitThunk+0x14
    000000f5320ffeb0 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x21

    SYMBOL_NAME: vhdmp!VhdmpiOpenBackingFileWithOptions+172
    MODULE_NAME: vhdmp
    IMAGE_NAME: vhdmp.sys
    STACK_COMMAND: .cxr 0xffffa28a74e50a00 ; kb

    Followup: MachineOwner

    So... If I understand this correctly the Function which is supposed to call my PostCallback fails because it, once again uses a pointer with the lower part all Zeroed. Sadly my debugger crashed so I don't have a lot of data - I checked the address of one of my functions tough:
    ?? LxFileMirror!FileMirrorAfterOpen 0xfffff802`5b1e1060

    Do you have any debugging Tipps for soemthing like this?
    Also - Is this stack trace to be trusted? or could it be corrupted or soemthing?

    Aaron Kelbsch
    Techit GmbH @ Germany

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,362

    @AaronK said:
    So, Quick update.

    Enabling the Verifier for both driver ended in instant Bluescreens for some reason.

    That's what you want! Post the !analyze -v of that crash.

    -scott
    OSR

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE