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

Home NTDEV
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/


Regarding blue screen while running DF tests on USB filter driver

Parinitha_KashyapParinitha_Kashyap Member - All Emails Posts: 20
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

Comments

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,825
    [email protected] 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, [email protected]
    Providenza & Boekelheide, Inc.

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

  • megs_rsmegs_rs Member Posts: 9

    @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,

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,825

    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, [email protected]
    Providenza & Boekelheide, Inc.

  • megs_rsmegs_rs Member Posts: 9

    @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!!!

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,825

    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?

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

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,825

    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, [email protected]
    Providenza & Boekelheide, Inc.

  • megs_rsmegs_rs Member Posts: 9

    @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?

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,315

    Sure.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,825

    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, [email protected]
    Providenza & Boekelheide, Inc.

  • megs_rsmegs_rs Member Posts: 9

    @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?

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,825

    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.

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

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,315

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

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

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • megs_rsmegs_rs Member Posts: 9

    @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!

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