Regarding blue screen while running DF tests on USB filter driver

Hello,

I am running DF tests on USB filter driver using HLK 1703 on a client
machine with windows 1703. Blue screens are caused due to bug check code:
0x0000007e (0xffffffffc0000005, 0xfffff803ddffef79, 0xffffcd81e4d33868,
0xffffcd81e4d330b0)

How can I debug this issue?

Thank you,
*Warm regards,*
Parinitha Kashyap

xxxxx@gmail.com wrote:

I am running DF tests on USB filter driver using HLK 1703 on a client
machine with windows 1703. Blue screens are caused due to bug check code:
0x0000007e (0xffffffffc0000005, 0xfffff803ddffef79,
0xffffcd81e4d33868, 0xffffcd81e4d330b0)

You need to hook up a kernel debugger, or at the very least get a dump
file and load the dump into windbg.  That’s  an access violation,
usually caused by touching freed memory or a bad address computation. 
The debugger’s !analyze -v command will tell you more.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

@Tim_Roberts said:
You need to hook up a kernel debugger, or at the very least get a dump
file and load the dump into windbg. That’s an access violation,
usually caused by touching freed memory or a bad address computation.Â
The debugger’s !analyze -v command will tell you more.

Hi Tim,

I have a similar problem in my DRIVER.

How can i “hook up a kernel debugger”?

I did the “!analyze -v” and that didn’t help me so much. You can see the result in this link.

Thanks a lot,

No, it doesn’t help much. The system is trying to restart the device and tried to use what looks like a user-mode address. How much stuff are you filtering? Remember that part of the WHQL testing involves “fuzzing”, where they send bullshit requests to your driver to make sure you fail them instead of taking action. If you are assuming that all requests you get are valid, that could be an issue.

@Parinitha_Kashyap,

Sorry to pollute your thread.

I opened another one but Admin closed it.

@Tim_Roberts said:
No, it doesn’t help much. The system is trying to restart the device and tried to use what looks like a user-mode address. How much stuff are you filtering? Remember that part of the WHQL testing involves “fuzzing”, where they send bullshit requests to your driver to make sure you fail them instead of taking action. If you are assuming that all requests you get are valid, that could be an issue.

@Tim_Roberts,

I am a very beginner in this subject (Windows DRIVERs). Then, i need a very baby steps…

How much stuff are you filtering?

I don’t know where this occur in the DRIVER loading.

This IRPs occurs in my DRIVER:

I am using the POSUSB source code made by Microsoft. I take it from this link.

It do exactly what i need to a Printer Device. I have a USB Printer and i need to emulate a serial port.

Remember that part of the WHQL testing involves “fuzzing”, where they send bullshit requests to your driver to make sure you fail them instead of taking action. If you are assuming that all requests you get are valid, that could be an issue.

I am not sure about this, but i am not using the WHQL testing. I am only loading my Kernel mode Driver in debugger mode and looking the result in another PC with windbg.

Thanks!!!

I’m sorry, I did not immediately notice you had hijacked another thread. This demonstrates the danger of doing so. You said you were having the same problem, but clearly you are not. You need to post a brand new question describing your situation and your problem in detail. Exactly what problem do you see, and at exactly what point?

Also allow me to point out that the driver binaries you cited would be old enough to drink, if they were a person. They are 21 years old. That’s older than Windows XP and Windows 2000. There is almost no chance that it follows the rules correctly.

Are you developing a driver, or are you just using this driver? This forum is designed for people who are writing their own drivers. If you’re just having trouble using an antique module, then you may need to go elsewhere.

@Tim_Roberts,

The said DRIVER does what I need. Can’t I try to bring that to the present day?

Can’t I ask for help from people who are very expert on the subject?

@“Peter_Viscarola_(OSR)” ,

Can I open a new topic as @Tim_Roberts suggested?

Sure.

Peter

You don’t have source code for the POSUSB driver, do you? I have had a couple of clients ask me about that over the decades, and I never found any source. If you don’t have source, then I’m not sure what you intend to do.

@Tim_Roberts ,

You don’t have source code for the POSUSB driver, do you?

Yes, i have. I putted some post early.

I have had a couple of clients ask me about that over the decades, and I never found any source.

Here is the link. I am happy to share with you. Use some file compress tool to extract. I extract the files using the Archive Manager from gnome package.

Then, Can you help to find the problem of this DRIVER?

It’s just a zip, although it’s quite dangerous these days to ask anyone to download an executable file from a random Eastern European web site.

Look, no one is going to debug this antique for you. You’re in for a long slog, and you may need to hire some help.

Having said that, I have spotted the problem. One of the big issues you face is that this source code was developed before there were any 64-bit implementations of Windows, and many foolish developers assumed pointers would always fit in 32 bits. The !analyze output looks like that’s the issue, because it’s trying to reference an address where the high 32 bits are zero. Your trace showed that the last IRP was QueryDeviceRelations for BusRelations. If you look at the QueryDeviceRelations code, in a chunk of code that is only there to handle Windows 98, it does

    irp->IoStatus.Information = (ULONG)CopyDeviceRelations(parentFdoExt->deviceRelations);

That’s the problem. CopyDeviceRelations is returning a 64-bit pointer, and the cast promptly truncates it to 32-bits. In the modern systems, the Information field is ULONG_PTR, which is 64-bits. That’s what it should cast to.

Mr. @Tim_Roberts renews his sainthood… one more time.

Thank you, Mr. Roberts, for finding this error for Mr. @megs_rs,

Peter

1 Like

@Tim_Roberts

It’s just a zip, although it’s quite dangerous these days to ask anyone to download an executable file from a random Eastern European web site.

This is the reason why I suggest you open it with compression tools.

Look, no one is going to debug this antique for you. You’re in for a long slog, and you may need to hire some help.

I didn’t ask for that. I just want a tip to go in the right direction to fix this.

One of the big issues you face is that this source code was developed before there were any 64-bit implementations of Windows, and many foolish developers assumed pointers would always fit in 32 bits. The !analyze output looks like that’s the issue, because it’s trying to reference an address where the high 32 bits are zero. Your trace showed that the last IRP was QueryDeviceRelations for BusRelations. If you look at the QueryDeviceRelations code, in a chunk of code that is only there to handle Windows 98, it does

That’s what I need. Now I know where I can try to find the problem.

Thank you so much!