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

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/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Debugging an x64 target with x86 WinDbg

Martin_GhazaryanMartin_Ghazaryan Member Posts: 25
Hi.

I'm attaching to an x64 Win7 target in a VM using x86 WinDbg on an x86 XP host machine. Here's the log from the debugger:

*********************************************************************
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Opened \\.\pipe\com_1
Waiting to reconnect...
Connected to Windows 7 7600 x64 target at (Wed Feb 17 17:07:37.984 2010 (GMT+4)), ptr64 TRUE
Kernel Debugger connection established.
Symbol search path is: W:\P\head\protectdrive\release_x64\x64
Executable search path is:
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrnlmp.exe -
Windows 7 Kernel Version 7600 MP (1 procs) Free x64
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02603000 PsLoadedModuleList = 0xfffff800`02840e50
System Uptime: not available
Break instruction exception - code 80000003 (first chance)
*** ERROR: Symbol file could not be found. Defaulted to export symbols for hal.dll -
hal!HalRegisterErrataCallbacks+0x3aee:
fffff800`02c2340a cc int 3
kd> g
The context is partially valid. Only x86 user-mode context is available.
WOW64 single step exception - code 4000001e (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
6c531437 7175 jno 6c5314ae
32.kd:x86> g
*********************************************************************

This is what bothers me:
"The context is partially valid. Only x86 user-mode context is available."

Particularly I'm interested in why it goes through some automatic context switch and can I even successfully debug my drivers in this way.


Thanks,
Martin

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    You can't debug 64 bit user mode code with the x86 debugger.
    You need to fix your symbols.
    It looks like you hit a breakpoint in WOW64 which is user mode.

    Bill Wandel

    -----Original Message-----
    From: [email protected]
    [mailto:[email protected]] On Behalf Of [email protected]
    Sent: Wednesday, February 17, 2010 9:40 AM
    To: Kernel Debugging Interest List
    Subject: [windbg] Debugging an x64 target with x86 WinDbg

    Hi.

    I'm attaching to an x64 Win7 target in a VM using x86 WinDbg on an x86 XP
    host machine. Here's the log from the debugger:

    *********************************************************************
    Microsoft (R) Windows Debugger Version 6.11.0001.404 X86 Copyright (c)
    Microsoft Corporation. All rights reserved.

    Opened \\.\pipe\com_1
    Waiting to reconnect...
    Connected to Windows 7 7600 x64 target at (Wed Feb 17 17:07:37.984 2010
    (GMT+4)), ptr64 TRUE Kernel Debugger connection established.
    Symbol search path is: W:\P\head\protectdrive\release_x64\x64
    Executable search path is:
    *** ERROR: Symbol file could not be found. Defaulted to export symbols for
    ntkrnlmp.exe - Windows 7 Kernel Version 7600 MP (1 procs) Free x64 Built by:
    7600.16385.amd64fre.win7_rtm.090713-1255
    Machine Name:
    Kernel base = 0xfffff800`02603000 PsLoadedModuleList = 0xfffff800`02840e50
    System Uptime: not available Break instruction exception - code 80000003
    (first chance)
    *** ERROR: Symbol file could not be found. Defaulted to export symbols for
    hal.dll -
    hal!HalRegisterErrataCallbacks+0x3aee:
    fffff800`02c2340a cc int 3
    kd> g
    The context is partially valid. Only x86 user-mode context is available.
    WOW64 single step exception - code 4000001e (first chance) First chance
    exceptions are reported before any exception handling.
    This exception may be expected and handled.
    6c531437 7175 jno 6c5314ae
    32.kd:x86> g
    *********************************************************************

    This is what bothers me:
    "The context is partially valid. Only x86 user-mode context is available."

    Particularly I'm interested in why it goes through some automatic context
    switch and can I even successfully debug my drivers in this way.


    Thanks,
    Martin

    ---
    WINDBG is sponsored by OSR

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at
    http://www.osronline.com/page.cfm?name=ListServer
  • Martin_GhazaryanMartin_Ghazaryan Member Posts: 25
    Thanks for the reply!

    I'm not doing a user mode debug, so how can I ignore that surprise WOW64 breakpoint and switch back into the previous context remaining attached to the system?
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    I don't know why you hit the breakpoint. I have used the x86 debugger to
    debug 64 bit Oses, including Server 2008 R2, without any problems. What
    happened after you hit g?
    You do need to fix your symbols.

    Bill Wandel

    -----Original Message-----
    From: [email protected]
    [mailto:[email protected]] On Behalf Of [email protected]
    Sent: Wednesday, February 17, 2010 11:26 AM
    To: Kernel Debugging Interest List
    Subject: RE:[windbg] Debugging an x64 target with x86 WinDbg

    Thanks for the reply!

    I'm not doing a user mode debug, so how can I ignore that surprise WOW64
    breakpoint and switch back into the previous context remaining attached to
    the system?

    ---
    WINDBG is sponsored by OSR

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at
    http://www.osronline.com/page.cfm?name=ListServer
  • Martin_GhazaryanMartin_Ghazaryan Member Posts: 25
    Yeah, it turned out there was a 32bit Norton Antivirus installed in the VM snapshot I was using -- quite a possible source of a first chance exception in WOW64. So I tried the same with a clean VM without any exceptions and context switches.

    Yes, I know I have to fix my symbols; just trying to figure out if it's possible to debug a 64bit system using a 32bit WinDbg.

    Thanks for help!
  • Ken_JohnsonKen_Johnson Member - All Emails Posts: 1,559
    That is only so for local user mode debugging. The 64-bit debuggers should work just fine debugging wow64 code over kd.

    But first I'd fix symbols in this case.

    - S

    -----Original Message-----
    From: Bill Wandel <[email protected]>
    Sent: Wednesday, February 17, 2010 7:51
    To: Kernel Debugging Interest List <[email protected]>
    Subject: RE: [windbg] Debugging an x64 target with x86 WinDbg


    You can't debug 64 bit user mode code with the x86 debugger.
    You need to fix your symbols.
    It looks like you hit a breakpoint in WOW64 which is user mode.

    Bill Wandel

    -----Original Message-----
    From: [email protected]
    [mailto:[email protected]] On Behalf Of [email protected]
    Sent: Wednesday, February 17, 2010 9:40 AM
    To: Kernel Debugging Interest List
    Subject: [windbg] Debugging an x64 target with x86 WinDbg

    Hi.

    I'm attaching to an x64 Win7 target in a VM using x86 WinDbg on an x86 XP
    host machine. Here's the log from the debugger:

    *********************************************************************
    Microsoft (R) Windows Debugger Version 6.11.0001.404 X86 Copyright (c)
    Microsoft Corporation. All rights reserved.

    Opened \\.\pipe\com_1
    Waiting to reconnect...
    Connected to Windows 7 7600 x64 target at (Wed Feb 17 17:07:37.984 2010
    (GMT+4)), ptr64 TRUE Kernel Debugger connection established.
    Symbol search path is: W:\P\head\protectdrive\release_x64\x64
    Executable search path is:
    *** ERROR: Symbol file could not be found. Defaulted to export symbols for
    ntkrnlmp.exe - Windows 7 Kernel Version 7600 MP (1 procs) Free x64 Built by:
    7600.16385.amd64fre.win7_rtm.090713-1255
    Machine Name:
    Kernel base = 0xfffff800`02603000 PsLoadedModuleList = 0xfffff800`02840e50
    System Uptime: not available Break instruction exception - code 80000003
    (first chance)
    *** ERROR: Symbol file could not be found. Defaulted to export symbols for
    hal.dll -
    hal!HalRegisterErrataCallbacks+0x3aee:
    fffff800`02c2340a cc int 3
    kd> g
    The context is partially valid. Only x86 user-mode context is available.
    WOW64 single step exception - code 4000001e (first chance) First chance
    exceptions are reported before any exception handling.
    This exception may be expected and handled.
    6c531437 7175 jno 6c5314ae
    32.kd:x86> g
    *********************************************************************

    This is what bothers me:
    "The context is partially valid. Only x86 user-mode context is available."

    Particularly I'm interested in why it goes through some automatic context
    switch and can I even successfully debug my drivers in this way.


    Thanks,
    Martin

    ---
    WINDBG is sponsored by OSR

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at
    http://www.osronline.com/page.cfm?name=ListServer


    ---
    WINDBG is sponsored by OSR

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

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!
Internals & Software Drivers 15 November 2021 Live, Online
Writing WDF Drivers 24 January 2022 Live, Online
Developing Minifilters 7 February 2022 Live, Online
Kernel Debugging 21 March 2022 Live, Online