Upper filter driver waitlock

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?

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);

On Nov 7, 2018, at 10:58 PM, Mak wrote:
>
> Tim worte:
>
>>> What ioctl codes?
>
> define IOCTL_NONPNP_METHOD_GET_GETPROPERTY <br>> 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, timr@probo.com
Providenza & Boekelheide, Inc.

Why do I even have to say that

Because, having already been sainted for the prodigious patience demonstrated by your repeated willingness to answer questions from “the least of us” you want to provide us all with an example to which we can aspire?

Better a patient person than a warrior,
one with self-control than one who takes a city.

Keep in mind that the OP is “a developer on the user land since many years”…

(so, now I promise I’m out of this thread)

Peter

Peter wrote:

Better a patient person than a warrior,
Tim wrote:
Do it right, or don’t do it at all.
This is far away from helpful.
English isn’t my first language and by the way I didn’t understand what you want to say with:

  • OP
  • … example to which we can aspire?

Better a patient person than a warrior,
one with self-control than one who takes a city.

The very first thing that comes up to my mind when I see this is “Chutiya The Warrior” (probably, alongside YahooMan) …

Judging from the way the OP reacts to the attempts to help him and to point out his mistakes to him, they must be his mates…

Anton Bassov

Better a patient person than a warrior,
one with self-control than one who takes a city.

This is what comes now into my mind:
Better than writing such sentence is to change yourself because yourself is it only one you can change.