none
Kernel debugging is enabled, but not working : host debugger does trap kernel exception/error(s) from the target ? RRS feed

  • Question

  • Hi,

    I'm developping a driver for a PCIe Card on Windows Embedded Standard 7 using KMDF.

    My developpement environment is :

    • VS2013RC + WDF 8.1 Preview,
    • A Win7Pro/SP1 as host machine
    • A WinEmb7Standard/SP1 as target machine
    • Both machine are connected via a serial connection COM1@115200

    I'm not able to debug my driver because the host debugger does not trap kernel exceptions/errors from the target.

    • My serial connection is OK (checked using putty on target/host).
    • Debugging mode into BCDEDIT is enabled :

    Gestionnaire de d‚marrage Windows
    ---------------------------------
    identificateur          {bootmgr}
    device                  partition=\Device\HarddiskVolume1
    description             Windows Boot Manager
    locale                  fr-FR
    inherit                 {globalsettings}
    default                 {current}
    resumeobject            {a965d34e-fe91-11d5-9360-a8b7151d56f6}
    displayorder            {current}
    toolsdisplayorder       {memdiag}
    timeout                 30

    Chargeur de d‚marrage Windows
    -----------------------------
    identificateur          {current}
    device                  partition=C:
    path                    \Windows\system32\winload.exe
    description             Windows Embedded Standard
    locale                  fr-FR
    inherit                 {bootloadersettings}
    bootdebug               Yes
    testsigning             Yes
    osdevice                partition=C:
    systemroot              \Windows
    resumeobject            {a965d34e-fe91-11d5-9360-a8b7151d56f6}
    nx                      OptIn
    bootux                  Disabled
    usefirmwarepcisettings  No
    debug                   Yes

    • Debugging mode into KDBGCTRL is enabled :

    Kernel debugger is enabled
    Kernel debugger auto-enable: false
    Kernel debugger enable block: false
    Kernel DbgPrint buffer size: 0x1000

    • Regedit WDF properties for debugging my driver are all ON:

    HKLM\SYSTEM\CurrentContromSet\services\<mydriver>\Parameters\Wdf\DebugBreakOnError is 1

    HKLM\SYSTEM\CurrentContromSet\services\<mydriver>\Parameters\Wdf\VerboseOn is 1

    HKLM\SYSTEM\CurrentContromSet\services\<mydriver>\Parameters\Wdf\VerifierOn is 1

    HKLM\SYSTEM\CurrentContromSet\services\<mydriver>\Parameters\Wdf\VerifyOn is 1


    Does someone have any clue to solve this issue ?

    Thanks.


    Monday, October 14, 2013 9:18 AM

Answers

  • Hi Joe,

    The motherboad of the target PC has only one COM for which port IO address can be changed (0x3f8, 0x02f8, 0x03e8 or 0x02e8) via the BIOS utility.

    After a few tests... I was able to get the kernel debugger working when I set the serial port address to 3F8/IRQ4 which was not the value configured in the BIOS when I got the target PC.

    Maybe, a few words about BIOS configuration would be welcome in the MSDN site.

    Thanks you all for the support.

    Cheers.
    Wednesday, October 16, 2013 9:58 AM

All replies

  • Are you debugging by using the WDK Visual Studio integration of the Windows debuggers, or by using WinDbg by itself? If you are using Visual Studio, I would suggest trying to use WinDbg to see if the issue also occurs in there.

    Max -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, October 14, 2013 5:19 PM
  • Hi Max,

    Thanks for your support.

    I've tested both tools with no result. I tried with KD, but same result.

    Note that the following env. var. are set :

    • _NT_DEBUG_PORT=com1
    • _NT_DEBUG_BAUD=115200

    When I launch Wingdb (File > Kernel Debug > COM > COM1/115200), the debugger display "waiting to reconnect" message and nothing else happens :

    Microsoft (R) Windows Debugger Version 6.3.9600.16384 AMD64
    Copyright (c) Microsoft Corporation. All rights reserved.

    Opened \\.\com1
    Waiting to reconnect...

    Cheers.

    Monday, October 14, 2013 6:20 PM
  • This usually means that the kernel debugger isn't connected at all. Did you follow the instructions on MSDN, especially the part about running "bcdedit /dbgsettings serial debugport:n baudrate:rate" on the target machine?

    If you provisioned the target machine with Visual Studio, then the above should be run during provisioning, but if you're doing it manually, then you need to run the commands yourself


    Max -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, October 14, 2013 6:33 PM
  • What kind of serial hardware is in the target machine? If it is not legacy serial hardware that is built into the chipset, and accessed via I/O ports, then it won't work for debugging.

    You cannot add a serial PCI card and use it for kernel debugging.

    You cannot plugin a USB/serial device and use it for kernel debugging.

    You have to have a machine that has serial support on the motherboard.

    Joe.

    Monday, October 14, 2013 6:45 PM
  • Max,

    I've configured my target computer using VS2013RC provisonning mechanism : Driver > Test > Configure Computers  > Provision computer and choose debugger settings
    Transport = Serial
    Port = COM1
    Baud = 115200

    BCDEDIT /dbgsettings (run as administrator) displays the following information :

    C:\Windows\system32>bcdedit /dbgsettings
    debugtype               Serial
    debugport               1
    baudrate                115200
    debugstart              Active
    L'opération a réussi.

    Cheers.
    Monday, October 14, 2013 6:59 PM
  • Hi Joe,

    It was a mistake that I have done (USB/Serial) in the past.

    But it is fixed now. I'm now using a DB9 serial to 10-pin motherboard slot plate adapter (see http://www.amazon.com/StarTech-com-9-Inch-Motherboard-Adapter-PLATE9M/dp/B00066HJAM/ref=sr_1_1?ie=UTF8&qid=1381777473&sr=8-1&keywords=StarTech.com+9+Pin+Serial+Male+to+10+Pin+Motherboard).

    (target) COM1 <= null-modem cable => COM1 (host) [tested using PUTTY/serial]

    Cheers.
    Monday, October 14, 2013 7:09 PM
  • Hi Max, hi Joe,

    If the IRQ/IO allocated by the BIOS differs from what the Windows kernel expects, then I can imagine that the connection will fail.

    What do you think?

    Cheers.
    Tuesday, October 15, 2013 12:54 PM
  • On your target machine, run bcdedit -enum all

    Send us the output.

    Do you have 2 motherboard serial connectors?  Is it really plugged into the com1 connector?

    The kernel is going to use whatever the standard com1 settings are.

    The kernel debugger does not use interrupts, so that is irrelevant, but if the hardware is not at the expected IO address, it won't work.  The following are the IO ports the kernel debugger uses if there isn't overloaded information in the kernel configuration.

    COM1_PORT   0x03f8

    COM2_PORT   0x02f8

    COM3_PORT   0x03e8

    COM4_PORT   0x02e8

    You might also try using lower baudrates - like 57600 or 19200.

    You have to have the same baudrate on both sides.  You can cycle the baudrate in the debugger easily from the windbg UI.

    It is possible your BIOS has some debug table entries that are causing the kernel debugger to NOT use port 1

    Joe.

    Tuesday, October 15, 2013 8:58 PM
  • Hi Joe,

    The motherboad of the target PC has only one COM for which port IO address can be changed (0x3f8, 0x02f8, 0x03e8 or 0x02e8) via the BIOS utility.

    After a few tests... I was able to get the kernel debugger working when I set the serial port address to 3F8/IRQ4 which was not the value configured in the BIOS when I got the target PC.

    Maybe, a few words about BIOS configuration would be welcome in the MSDN site.

    Thanks you all for the support.

    Cheers.
    Wednesday, October 16, 2013 9:58 AM
  • I'm facing a similar problem where I cannot connect to com port on the target system.
    But in my case the com port io address range of 0x3f8-0x3ff is being occupied by the PCI bus. hence the com port is not configured and inaccessible. Has someone seen this kind of issue before? is there any possible solution for this??
    Friday, March 7, 2014 9:17 AM