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

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

Upper filter driver waitlock

MakMak Member Posts: 20

I wrote an upper filter driver and on the PASSIVE_LEVEL I use

WdfWaitLockAcquire(driverData->lockHandle, NULL);

that no second access is possible. What must I do, if I want to lock/access the same code from dispatch_level (ServiceCallback)?
I tried Waitlock and Spinlock but always get a bugcheck.

«1

Comments

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,372
    via Email
    You need to use a spin lock if you must synchronize at dispatch level. What is the output of !analyze -v for the bugcheck in the service callback?

    Bent from my phone
    ________________________________
    From: Mak
    Sent: Saturday, November 3, 2018 8:12:45 AM
    To: Doron Holan
    Subject: [NTDEV] Upper filter driver waitlock

    OSR https://na01.safelinks.protection.outlook.com/?url=https://community.osr.com/&data=02|01|[email protected]|671d9d1508c54aa62a2308d6419ecfef|72f988bf86f141af91ab2d7cd011db47|1|0|636768547706168845&sdata=u8KiAUr1QX55lxXs8n1pE01KeMhYGWWbqwwEvuy1k9Y=&reserved=0
    Mak started a new discussion: Upper filter driver waitlock

    I wrote an upper filter driver and on the PASSIVE_LEVEL I use

    > WdfWaitLockAcquire(driverData->lockHandle, NULL);

    that no second access is possible. What must I do, if I want to lock/access the same code from dispatch_level (ServiceCallback)?

    I tried Waitlock and Spinlock but always get a bugcheck.
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 6,794

    if I want to lock/access the same code from dispatch_level

    You must always use the spin lock -- You have to use the same lock to guard a given block of data. If that data is never accessed at IRQL DISPATCH_LEVEL or above, you use a mutex. If that data is ever in any data path accessed at IRQL DISPATCH_LEVEL, then you must use a Spin Lock (prior to accessing the data at any IRQL, even at IRQL PASSIVE_LEVEL). The IRQL associated with a locking primitive indicates the maximum IRQL at which the lock may be obtained.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • MakMak Member Posts: 20

    Thanks. It works now.
    One question left:
    I communicate with the user land via Inverted call with a ring buffer. In this scenario I have two functions. One is called inside the driver to place the data in the queue and the second is if the call comes from the user land with IOCTL to get the data. I have now set a Spin Lock in this two functions. Is this correct? I have no problem with the inverted call without Spin Lock. I only want to know if this is necessary to make the code save.

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,372
    via Email
    Yes you need a spin lock to synchronize the writing and reading of the data in the ServiceCallback and the io processing routine.

    d

    Bent from my phone
    ________________________________
    From: Mak
    Sent: Sunday, November 4, 2018 1:53:34 AM
    To: Doron Holan
    Subject: Re: [NTDEV] Upper filter driver waitlock

    OSR https://na01.safelinks.protection.outlook.com/?url=https://community.osr.com/&data=02|01|[email protected]|10bf15aeabac45d569ae08d6423301c5|72f988bf86f141af91ab2d7cd011db47|1|0|636769184188358590&sdata=O+YVBRBA1o5HAGkU/US6UrEW8V3liLEE+G1qWJFagVg=&reserved=0
    Mak commented on Upper filter driver waitlock

    Thanks. It works now.

    One question left:

    I communicate with the user land via Inverted call with a ring buffer. In this scenario I have two functions. One is called inside the driver to place the data in the queue and the second is if the call comes from the user land with IOCTL to get the data. I have now set a Spin Lock in this two functions. Is this correct? I have no problem with the inverted call without Spin Lock. I only want to know if this is necessary to make the code save.
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 6,794

    I only want to know if this is necessary to make the code safe

    We really can't tell you that, without seeing all your code (and, no, that is not an invitation to post it here). In general, any time you share data between multiple separate threads of processing, you need a lock to ensure that both threads don't attempt to update the same data data at the same time. For example, you don't want one routine trying to put something ON a list, while at the same time you have another routine trying to take something OFF that same list. If the timing is "unlucky", the two threads can interfere with each other, right? So, each thread takes out a lock before manipulating the shared data (the list, in the example I just cited)... THEN does the manipulation (insert or remove from the list, for example)... and then releases the lock. The lock ensures that the manipulation of the shared data is done without the other thread of processing interfering, that is it ensures the manipulation is done "atomically."

    This is a general precept of how one makes things thread-safe. It's not a driver specific thing. Though the TYPES of locks you can use (wait or spin) are definitely specific to the world of drivers.

    Hope that helps,

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • MakMak Member Posts: 20

    Peter, I am a developer on the user land since many years and I know for what we need locks. The problem is that I have not so much knowledge how in general the concept in the driver land are. Sometimes it can be unnecessary to use locks because the system serialize the things. This was the reason for my question.
    Doron answered my question already very well.

  • MakMak Member Posts: 20

    Since I use the locks I get the following bugcheck and have no idea where I must look in the code:
    Loading unloaded module list
    ........Unable to enumerate user-mode unloaded modules, Win32 error 0n30


    • *
    • Bugcheck Analysis *
    • *

    Use !analyze -v to get detailed debugging information.

    BugCheck 7E, {ffffffffc0000005, fffff801fbd24c7b, ffff970dc858e598, ffff970dc858dde0}

    *** ERROR: Module load completed but symbols could not be loaded for Ch64USB.sys
    Probably caused by : Ch64USB.sys ( Ch64USB+14c7b )

    Followup: MachineOwner

    nt!DbgBreakPointWithStatus:
    fffff800`f68598d0 cc int 3
    0: kd> !analyze -v


    • *
    • Bugcheck Analysis *
    • *

    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: fffff801fbd24c7b, The address that the exception occurred at
    Arg3: ffff970dc858e598, Exception Record Address
    Arg4: ffff970dc858dde0, Context Record Address

    Debugging Details:

    KEY_VALUES_STRING: 1

    STACKHASH_ANALYSIS: 1

    TIMELINE_ANALYSIS: 1

    DUMP_CLASS: 1

    DUMP_QUALIFIER: 0

    BUILD_VERSION_STRING: 17134.1.amd64fre.rs4_release.180410-1804

    DUMP_TYPE: 0

    BUGCHECK_P1: ffffffffc0000005

    BUGCHECK_P2: fffff801fbd24c7b

    BUGCHECK_P3: ffff970dc858e598

    BUGCHECK_P4: ffff970dc858dde0

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

    FAULTING_IP:
    Ch64USB+14c7b
    fffff801`fbd24c7b 0fb616 movzx edx,byte ptr [rsi]

    EXCEPTION_RECORD: ffff970dc858e598 -- (.exr 0xffff970dc858e598)
    ExceptionAddress: fffff801fbd24c7b (Ch64USB+0x0000000000014c7b)
    ExceptionCode: c0000005 (Access violation)
    ExceptionFlags: 00000000
    NumberParameters: 2
    Parameter[0]: 0000000000000000
    Parameter[1]: 00000000b02e6a50
    Attempt to read from address 00000000b02e6a50

    CONTEXT: ffff970dc858dde0 -- (.cxr 0xffff970dc858dde0)
    rax=ffffd98db0e46030 rbx=0000000000000001 rcx=fffff801fbd2eb40
    rdx=00000000b02e6a50 rsi=00000000b02e6a50 rdi=fffff801fbd2ba90
    rip=fffff801fbd24c7b rsp=ffff970dc858e7d0 rbp=fffff801fbd29630
    r8=0000000000000009 r9=0000000000000000 r10=ffffd98db17d0fa0
    r11=ffff970dc858e8a0 r12=ffffd98db0e46180 r13=ffffd98db0e46030
    r14=0000000000000009 r15=fffff801fbd29600
    iopl=0 nv up ei pl zr na po nc
    cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010246
    Ch64USB+0x14c7b:
    fffff801fbd24c7b 0fb616 movzx edx,byte ptr [rsi] ds:002b:00000000b02e6a50=??
    Resetting default scope

    CPU_COUNT: 4

    CPU_MHZ: 5da

    CPU_VENDOR: GenuineIntel

    CPU_FAMILY: 6

    CPU_MODEL: 5c

    CPU_STEPPING: 9

    CPU_MICROCODE: 6,5c,9,0 (F,M,S,R) SIG: 32'00000000 (cache) 32'00000000 (init)

    DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

    PROCESS_NAME: System

    CURRENT_IRQL: 0

    FOLLOWUP_IP:
    Ch64USB+14c7b
    fffff801`fbd24c7b 0fb616 movzx edx,byte ptr [rsi]

    BUGCHECK_STR: AV

    READ_ADDRESS: 00000000b02e6a50

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

    EXCEPTION_PARAMETER2: 00000000b02e6a50

    ANALYSIS_SESSION_HOST: WIN10WORK

    ANALYSIS_SESSION_TIME: 11-06-2018 09:38:07.0276

    ANALYSIS_VERSION: 10.0.17763.1 amd64fre

    LAST_CONTROL_TRANSFER: from fffff801fbd1558a to fffff801fbd24c7b

    STACK_TEXT:
    ffff970dc858e7d0 fffff801fbd1558a : ffffd98db0e46030 fffff801fbd2eb40 ffffd98db0e46180 0000000000000000 : Ch64USB+0x14c7b
    ffff970dc858e830 fffff801fbd14012 : ffffd98db4b3b450 fffff800f676a560 ffffd98db52e8498 ffffd98db0e46180 : Ch64USB+0x558a
    ffff970dc858e940 fffff801fbd11fc4 : ffffd98db0e46030 ffffd98db61f31e0 ffffd98db4b3b450 0000000000000000 : Ch64USB+0x4012
    ffff970dc858e990 fffff800f66c2199 : 0000000000000000 ffff970dc858eb18 0000000000000000 ffff970dc858ea70 : Ch64USB+0x1fc4
    ffff970dc858e9d0 fffff801fc215c2f : 0000000000000000 0000000000000000 ffffea9826d1f5cc 0000000000000000 : nt!IofCallDriver+0x59
    ffff970dc858ea10 fffff801fc2161f1 : ffffd98db530c280 0000000000000000 fffff801f860a6c0 fffff801f836e4cc : hidusb!HumGetPortStatus+0x8f
    ffff970dc858eaa0 fffff800f67c5a9c : ffffd98db61f31e0 0000000000000000 0000000000000000 0000000000000100 : hidusb!HumResetWorkItem+0x61
    ffff970dc858eb10 fffff800f671f285 : 0000000000000100 ffffd98db0736040 fffff800f67c5970 7f2222220000000c : nt!IopProcessWorkItem+0x12c
    ffff970dc858eb80 fffff800f67a2e37 : ffffd98db0736040 0000000000000080 ffffd98db0303440 ffffd98db0736040 : nt!ExpWorkerThread+0xf5
    ffff970dc858ec10 fffff800f6859116 : ffffc28123179180 ffffd98db0736040 fffff800f67a2df0 6cc1166ccb2be5c0 : nt!PspSystemThreadStartup+0x47
    ffff970dc858ec60 0000000000000000 : ffff970dc858f000 ffff970dc8589000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16

    THREAD_SHA1_HASH_MOD_FUNC: f5b4ace2adf39990f92c24669368e0ec71708e59

    THREAD_SHA1_HASH_MOD_FUNC_OFFSET: e3eb8ce004d8d64f72274c1e0ef735d7b84651cf

    THREAD_SHA1_HASH_MOD: dcb03cc04fbc0323c9cf8317ab1160cd6291736a

    FAULT_INSTR_CODE: 4c16b60f

    SYMBOL_STACK_INDEX: 0

    SYMBOL_NAME: Ch64USB+14c7b

    FOLLOWUP_NAME: MachineOwner

    MODULE_NAME: Ch64USB

    IMAGE_NAME: Ch64USB.sys

    DEBUG_FLR_IMAGE_TIMESTAMP: 50868011

    STACK_COMMAND: .cxr 0xffff970dc858dde0 ; kb

    BUCKET_ID_FUNC_OFFSET: 14c7b

    FAILURE_BUCKET_ID: AV_Ch64USB!unknown_function

    BUCKET_ID: AV_Ch64USB!unknown_function

    PRIMARY_PROBLEM_CLASS: AV_Ch64USB!unknown_function

    TARGET_TIME: 2018-11-06T08:37:27.000Z

    OSBUILD: 17134

    OSSERVICEPACK: 0

    SERVICEPACK_NUMBER: 0

    OS_REVISION: 0

    SUITE_MASK: 272

    PRODUCT_TYPE: 1

    OSPLATFORM_TYPE: x64

    OSNAME: Windows 10

    OSEDITION: Windows 10 WinNt TerminalServer SingleUserTS

    OS_LOCALE:

    USER_LCID: 0

    OSBUILD_TIMESTAMP: 2018-08-03 05:10:45

    BUILDDATESTAMP_STR: 180410-1804

    BUILDLAB_STR: rs4_release

    BUILDOSVER_STR: 10.0.17134.1.amd64fre.rs4_release.180410-1804

    ANALYSIS_SESSION_ELAPSED_TIME: 12f6

    ANALYSIS_SOURCE: KM

    FAILURE_ID_HASH_STRING: km:av_ch64usb!unknown_function

    FAILURE_ID_HASH: {f0a075df-a4e3-29fb-7038-fd226ffd6fc4}

    Followup: MachineOwner

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 6,794

    I am a developer on the user land since many years and I know for what we need locks

    Good for you. Wait... are you taking offense and scolding me, because I spent time answering your question and trying to be sure you understood the underlying concepts?

    :o

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 396
    via Email
    Can we see some source around the bugcheck?

    On Tue, Nov 6, 2018 at 11:01 AM Peter_Viscarola_(OSR)
    wrote:

    > OSR https://community.osr.com/
    > Peter_Viscarola_(OSR) commented on Upper filter driver waitlock
    >
    > > I am a developer on the user land since many years and I know for what
    > we need locks
    >
    > Good for you. Wait... are you taking offense and scolding me, because I
    > spent time answering your question and trying to be sure you understood the
    > underlying concepts?
    >
    >
    >
    > Peter
    >
    > --
    > Reply to this email directly or follow the link below to check it out:
    > https://community.osr.com/discussion/comment/291310#Comment_291310
    >
    > Check it out:
    > https://community.osr.com/discussion/comment/291310#Comment_291310
    >
  • MakMak Member Posts: 20

    Peter, sorry if I answered in a way that bother you. I thank you very much and the others to answer my sometimes not so deeply grounded questions.

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,372
    via Email
    Fix your OS and private driver symbols first
  • MBondMBond Member - All Emails Posts: 846
    via Email
    Also, where possible the interlocked family of functions can / should be used to create so called
  • MakMak Member Posts: 20

    Jamey_Kirby: Can we see some source around the bugcheck?
    That is the problem. I can not say at the moment where in the code the bugcheck occurres exactly. If I can reproduce the bug, I will come back.

  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 396
    via Email
    Well, it is somewhere around here:

    ffff970dc858e7d0 fffff801fbd1558a : ffffd98db0e46030 fffff801fbd2eb40
    ffffd98db0e46180 0000000000000000 : Ch64USB+0x14c7b
    ffff970dc858e830 fffff801fbd14012 : ffffd98db4b3b450 fffff800f676a560
    ffffd98db52e8498 ffffd98db0e46180 : Ch64USB+0x558a
    ffff970dc858e940 fffff801fbd11fc4 : ffffd98db0e46030 ffffd98db61f31e0
    ffffd98db4b3b450 0000000000000000 : Ch64USB+0x4012
    ffff970dc858e990 fffff800f66c2199 : 0000000000000000 ffff970dc858eb18
    0000000000000000 ffff970dc858ea70 : Ch64USB+0x1fc4
    ffff970dc858e9d0 fffff801fc215c2f : 0000000000000000 0000000000000000
    ffffea9826d1f5cc 0000000000000000 : nt!IofCallDriver+0x59

    Start with your IoCallDriver() and work your way down.



    On Tue, Nov 6, 2018 at 11:46 AM Mak
    wrote:

    > OSR https://community.osr.com/
    > Mak commented on Upper filter driver waitlock
    >
    > Jamey_Kirby: Can we see some source around the bugcheck?
    >
    > That is the problem. I can not say at the moment where in the code the
    > bugcheck occurres exactly. If I can reproduce the bug, I will come back.
    >
    > --
    > Reply to this email directly or follow the link below to check it out:
    > https://community.osr.com/discussion/comment/291316#Comment_291316
    >
    > Check it out:
    > https://community.osr.com/discussion/comment/291316#Comment_291316
    >
  • MakMak Member Posts: 20

    If I search my code, I cant find a function with the name IofCallDriver or more reduced "CallDriver".

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,372
    via Email
    IofCallDriver == IoCallDriver. You need to fix the symbols for your driver to have any chance at root causing the issue
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 6,794

    Fix your symbols. Read or watch this. Unless you already know how to do that, too.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • MakMak Member Posts: 20

    I set the symbols path to:
    _NT_SYMBOL_PATH=symsrv*symsrv.dll*D:\Symbols*http://msdl.microsoft.com/download/symbols
    but If I look on the driver the symbols are always loaded to "C:\ProgramData\dbg\sym".
    I checked the environment variable in VS and under System.
    The symbols loading summary is:
    ************* Symbol Loading Error Summary **************
    Module name Error
    clipsp No error - symbol load deferred
    WdFilter The system cannot find the file specified
    igdkmd64 The system cannot find the file specified
    drmk The system cannot find the file specified
    TeeDriverW8x64 The system cannot find the file specified
    RtsP2Stor The system cannot find the file specified
    Netwtw04 The system cannot find the file specified
    iaLPSS2_UART2 The system cannot find the file specified
    iaLPSS2_SPI The system cannot find the file specified
    IntcDAud The system cannot find the file specified
    kbfiltr No error - symbol load deferred
    ibtusb The system cannot find the file specified
    Ch64USB The system cannot find the file specified
    peauth The system cannot find the file specified
    WdNisDrv The system cannot find the file specified

    Is this ok?

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,665
    via Email
    Mak wrote:
    > Since I use the locks I get the following bugcheck and have no idea where I must look in the code:
    >
    >
    > * *
    > * Bugcheck Analysis *
    > * *
    >
    > SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
    > ...
    > Arguments:
    > Arg1: ffffffffc0000005, The exception code that was not handled
    > Arg2: fffff801fbd24c7b, The address that the exception occurred at
    > Arg3: ffff970dc858e598, Exception Record Address
    > Arg4: ffff970dc858dde0, Context Record Address
    > ...
    > Attempt to read from address 00000000b02e6a50
    >
    > CONTEXT: ffff970dc858dde0 -- (.cxr 0xffff970dc858dde0)
    > rax=ffffd98db0e46030 rbx=0000000000000001 rcx=fffff801fbd2eb40
    > rdx=00000000b02e6a50 rsi=00000000b02e6a50 rdi=fffff801fbd2ba90
    > rip=fffff801fbd24c7b rsp=ffff970dc858e7d0 rbp=fffff801fbd29630
    > r8=0000000000000009 r9=0000000000000000 r10=ffffd98db17d0fa0
    > r11=ffff970dc858e8a0 r12=ffffd98db0e46180 r13=ffffd98db0e46030
    > r14=0000000000000009 r15=fffff801fbd29600
    > iopl=0 nv up ei pl zr na po nc
    > cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010246
    > Ch64USB+0x14c7b:
    > fffff801fbd24c7b 0fb616 movzx edx,byte ptr [rsi] ds:002b:00000000b02e6a50=??

    That seems crystal clear.  You're trying to read a user-mode address
    within your driver.


    > I set the symbols path to:
    > _NT_SYMBOL_PATH=symsrv*symsrv.dll*D:\Symbols*http://msdl.microsoft.com/download/symbols
    > but If I look on the driver the symbols are always loaded to "C:\ProgramData\dbg\sym".

    Did you copy your own driver's symbols there?  I'm guessing you didn't. 
    In that case, you probably want to add the directory containing your
    driver's symbols to the .sympath.

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

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 6,794

    Is this ok?

    If you examine the kernel stack and it has symbols resolved, then yes. If not, then no.

    Let me guess: You didn't read that page I sent you to, or watch that video... did you. No, I bet you didn't.

    Seems I'm pretty much wasting my time here. Good luck, OP...

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 396
    via Email
    In Mak's defense, the link did not come through in the email posting. I
    looked for it as I always want to read what you recommend :)



    On Tue, Nov 6, 2018 at 4:23 PM Peter_Viscarola_(OSR)
    wrote:

    > OSR https://community.osr.com/
    > Peter_Viscarola_(OSR) commented on Upper filter driver waitlock
    >
    > > Is this ok?
    >
    > If you examine the kernel stack and it has symbols resolved, then yes. If
    > not, then no.
    >
    > Let me guess: You didn't read that page I sent you to, or watch that
    > video... did you. No, I bet you didn't.
    >
    > Seems I'm pretty much wasting my time here. Good luck, OP...
    >
    > Peter
    >
    > --
    > Reply to this email directly or follow the link below to check it out:
    > https://community.osr.com/discussion/comment/291325#Comment_291325
    >
    > Check it out:
    > https://community.osr.com/discussion/comment/291325#Comment_291325
    >
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 6,794

    In Mak's defense, the link did not come through in the email

    Yet YOU managed to figure it out. And I’ll wager that you need a tutorial about how to setup the WinDbg symbol search path even less than I do.

    Yeah.

    P

    Peter Viscarola
    OSR
    @OSRDrivers

  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 396
    via Email
    LOL. Well, I surely know how to do my job :) Others may be better, and I
    rarely need the kernel symbols. Usually, my own symbols suffice. I guess it
    is a matter of knowing your environment and your code.


    On Tue, Nov 6, 2018 at 8:33 PM Peter_Viscarola_(OSR)
    wrote:

    > OSR https://community.osr.com/
    > Peter_Viscarola_(OSR) commented on Upper filter driver waitlock
    >
    > > In Mak's defense, the link did not come through in the email
    >
    > Yet YOU managed to figure it out. And I’ll wager that you need a tutorial
    > about how to setup the WinDbg symbol search path even less than I do.
    >
    > Yeah.
    >
    > P
    >
    > --
    > Reply to this email directly or follow the link below to check it out:
    > https://community.osr.com/discussion/comment/291328#Comment_291328
    >
    > Check it out:
    > https://community.osr.com/discussion/comment/291328#Comment_291328
    >
  • MakMak Member Posts: 20

    Peter, I read and watched that article. The search path is set correctly but as I mentioned above the pdb are loaded on the c drive. If I delete the symbols on the c drive they are loaded again. It seems my settings are ignored "d:\Symbols".
    If I open the symbol path in windbg I also see the path to my driver pdb. By the way if the program crashes on other places I see in the stack trace my functions and part of my function code. The things are not totally wrong.
    This is from the symbol path dialog:
    srvD:\symbolshttps://msdl.microsoft.com/download/symbols;D:\project\sys\x64\Debug

  • MakMak Member Posts: 20

    Tim:

    That seems crystal clear. You're trying to read a user-mode address

    within your driver.
    What is wrong about that? I communicate with the driver and copy some data to driver string lists.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,665
    edited November 7 via Email
    Mak wrote:
    >>> That seems crystal clear. You're trying to read a user-mode address within your driver.
    > What is wrong about that? I communicate with the driver and copy some data to driver string lists.

    How, exactly, are you doing that? Are you passing addresses in your ioctl data? That is a HUGE mistake. It is tricky to handle user-mode addresses in a driver. You have to be absolutely sure that your process is still in the page tables (which we call "the process context"). If you are using KMDF, then your EvtIoDeviceControl is NOT called in the original process context, so any of that processes addresses will be invalid. Even if you are in the proper process context, the user-mode pages can get freed at any point, causing a blue screen. You have to use "probe and lock" to lock the pages into memory and convert to a kernel mode address.

    Pass your data in the ioctl buffers. Don't ever pass addresses.

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

  • MakMak Member Posts: 20

    Tim worte:

    How, exactly, are you doing that?

    • CreateFile with overlapped structure
    • IOCTL... for getting the buffer length
    • IOCTL... to get and set data, the buffer is crc and length checked
    • all data are copied into NopagedPool unicode string array memory
      I have no lock while I am doing this but locks at the moment the data are placed into the lists.
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,665
    via Email
    Mak wrote:
    >>> How, exactly, are you doing that?
    > * CreateFile with overlapped structure
    > * IOCTL... for getting the buffer length
    > * IOCTL... to get and set data, the buffer is crc and length checked
    > * all data are copied into NopagedPool unicode string array memory

    What ioctl codes?  Is it possible you are using METHOD_NEITHER? What do
    your "get" and "set" buffers look like?

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

  • MakMak Member Posts: 20

    Tim worte:

    What ioctl codes?

    define IOCTL_NONPNP_METHOD_GET_GETPROPERTY \

    CTL_CODE( FILEIO_TYPE, 0x902, METHOD_BUFFERED , FILE_ANY_ACCESS  )
    

    ...
    this is the pattern which all get follows:
    // IOCTL_NONPNP_METHOD_GET_BUFFER_SIZE

        status = WdfRequestRetrieveInputBuffer(Request, 0, (PVOID*)&inBuf, &bufSize);
        if (!NT_SUCCESS(status)  || bufSize < sizeof(ULONG)) {
            status = STATUS_INSUFFICIENT_RESOURCES;
            break;
        }
    
        status = WdfRequestRetrieveOutputBuffer(Request, 0, (PVOID*)&buffer, &bufSize);
        if (!NT_SUCCESS(status)) {
            break;
        }
    
        if (bufSize == sizeof(ULONG))
        {
            *((USHORT*)buffer) = (USHORT)TRANSFERBUFFER_SIZE;
        }
        WdfRequestSetInformation(Request, OutputBufferLength);
    
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,665
    via Email
    On Nov 7, 2018, at 10:58 PM, Mak wrote:
    >
    > Tim worte:
    >
    >>> What ioctl codes?
    >
    > define IOCTL_NONPNP_METHOD_GET_GETPROPERTY \
    > CTL_CODE( FILEIO_TYPE, 0x902, METHOD_BUFFERED , FILE_ANY_ACCESS )
    > ...
    >
    > this is the pattern which all get follows:
    >
    > // IOCTL_NONPNP_METHOD_GET_BUFFER_SIZE

    Honestly. Do people really not know how to ask questions to get help? You showed me the define for one ioctl, and the code for the other. Did that really seem like a good idea? Which one is causing your crash? I assume it's not the "get buffer size" ioctl, since the code you showed doesn't even use the input buffer. In that, case why on earth would that be the one you chose to show us? SHOW US THE CODE THAT IS BROKEN. Why do I even have to say that?

    And if this is really an upper filter driver, then it is obviously a PNP driver. WHY on earth would you keep naming your ioctls IOCTL_NONPNP_xxx? It drives me absolutely bonkers that people blindly copy code from the samples and keep the same, obviously non-applicable names for constants, functions, and files. Take a little care with your software engineering. Do it right, or don't do it at all.

    Man, I must be in a bad mood.

    > status = WdfRequestRetrieveInputBuffer(Request, 0, (PVOID*)&inBuf, &bufSize); if (!NT_SUCCESS(status) || bufSize < sizeof(ULONG)) { status = STATUS_INSUFFICIENT_RESOURCES; break; } status = WdfRequestRetrieveOutputBuffer(Request, 0, (PVOID*)&buffer, &bufSize); if (!NT_SUCCESS(status)) { break; } if (bufSize == sizeof(ULONG)) { *((USHORT*)buffer) = (USHORT)TRANSFERBUFFER_SIZE; } WdfRequestSetInformation(Request, OutputBufferLength);

    Why do you require the user to provide an input buffer of 4 bytes and fetch its address, when you don't use the input buffer at all? If this is an output-only ioctl, then write it as an output-only ioctl. Skip the input buffer altogether. And why do you require the output buffer to be a ULONG when you are only returning a USHORT? And why do you go to the trouble of casting the constant to a USHORT at all? Why not just write *buffer = TRANSFERBUFFER_SIZE? And if it is a constant, as an all-caps value should always be, then why even have an ioctl? Why not just put it in a common #include file?

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

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

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!