Upper filter driver waitlock

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
>

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.

Fix your OS and private driver symbols first

Also, where possible the interlocked family of functions can / should be used to create so called

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.

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
>

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

IofCallDriver == IoCallDriver. You need to fix the symbols for your driver to have any chance at root causing the issue

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

Peter

I set the symbols path to:
_NT_SYMBOL_PATH=symsrvsymsrv.dllD:\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?

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.

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

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

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
>

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

LOL. Well, I surely know how to do my job :slight_smile: 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
>

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

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.

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

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?