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

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/


WinDBG kernel-mode environment settings that can cause a Heisenbug

SynthwaveSynthwave Member Posts: 7

Hello,

I'm running into a bug somewhere in a kernel-mode driver I'm writing. However, I can't debug it because it vanishes whenever a kernel-mode debugger is attached. What WinDBG/KD behavior might be causing this difference in execution? And how can I disable this behavior or work around it to debug the issue?

Thanks in advance,
Synthwave

Comments

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,642
    via Email
    On Oct 2, 2018, at 6:02 PM, Synthwave wrote:
    >
    > I'm running into a bug somewhere in a kernel-mode driver I'm writing. However, I can't debug it because it vanishes whenever a kernel-mode debugger is attached. What WinDBG/KD behavior might be causing this difference in execution? And how can I disable this behavior or work around it to debug the issue?

    The most common issue is subtle timing effects, especially if you have KdPrints in your driver. KdPrints with the debugger attached take a REALLY long time, computationally speaking. Do you have a lot of KdPrint traces?

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

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

  • SynthwaveSynthwave Member Posts: 7

    @Tim_Roberts said:

    The most common issue is subtle timing effects, especially if you have KdPrints in your driver. KdPrints with the debugger attached take a REALLY long time, computationally speaking. Do you have a lot of KdPrint traces?

    The problematic part of the code doesn't have any KdPrints. The kernel-mode driver simply takes some data from user-mode, processes it, and writes it to some register. It also reads a register and brings the results back to user-mode. Could something else be causing timing issues?

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

    I’m afraid... You’re going to have to describe the bug for us, in order for us to be able to help you.

    You could start by explaining what you mean by “Writes it to some register”, maybe.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • SynthwaveSynthwave Member Posts: 7
    edited October 2018

    @Peter_Viscarola said:
    I’m afraid... You’re going to have to describe the bug for us, in order for us to be able to help you.

    You could start by explaining what you mean by “Writes it to some register”, maybe.

    I'm not entirely sure what the cause of the bug is, because attempting to debug it makes it disappear. My driver deals with a device that has its own processor. It uses WRITE_REGISTER_ULONG() and READ_REGISTER_ULONG() to read and write memory-mapped registers on the device. It writes to a register to request tests, then writes to another register to request the results. My bug is that the tests don't run properly without a kernel debugger attached.

    However, I've been using some unconventional ways to debug it, and it seems like KeDelayExecutionThread() only delays execution when a debugger is attached, and fails to delay it when a debugger is detached. This could be causing the bug.

    Do you know why that could be?


    Edit: This might no longer be a WinDBG question at this point, so let me know if there's a better place to post it.

    Post edited by Synthwave on
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