1

Closed

Windbg hangs forever when using <tab> in !py

description

Hi,

Windbg hangs forever and stops responding when <tab> is pressed inside the python interpreter (started with "!py"). The only solution I found is to kill windbg and restart it.

Steps to reproduce:
2: kd> .load pykd
2: kd> !py
Python 3.6.1 (v3.6.1:69c0db5, Mar 21 2017, 18:41:36) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> pykd.dbg<tab>
After <tab> is pressed, windbg doesn't respond.


Version infos:
2: kd> !pykd.info

pykd bootstrapper version: 2.0.0.13

Installed python:

Version:        Status:     Image:
------------------------------------------------------------------------------
* 3.6 x86-64    Unloaded    C:\Python36\python36.dll
2: kd> !pip show pykd
Name: pykd
Version: 0.3.2.8
Summary: python windbg extension
Home-page: http://pykd.codeplex.com
Author: UNKNOWN
Author-email: pykd.codeplex@hotmail.com
License: Ms-PL
Location: c:\python36\lib\site-packages
Requires: 
2: kd> version
Windows 10 Kernel Version 15063 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 15063.0.amd64fre.rs2_release.170317-1834
Machine Name:
Kernel base = 0xfffff802`b8406000 PsLoadedModuleList = 0xfffff802`b87525e0
Debug session time: Fri Aug 18 11:09:59.536 2017 (UTC + 2:00)
System Uptime: 0 days 0:07:31.821
Remote KD: KdSrv:Server=@{<Local>},Trans=@{USB2:TARGETNAME=xxx}

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

command line: '"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe"  -k usb:targetname=xxx'  Debugger Process 0x1A2C 
dbgeng:  image 10.0.15063.137, built Thu Jan  1 01:00:00 1970
        [path: C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dbgeng.dll]
dbghelp: image 10.0.15063.137, built Thu Jan  1 01:00:00 1970
        [path: C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dbghelp.dll]
        DIA version: 24610
Extension DLL search Path: [...]
Extension DLL chain:
    pykd: image 2.0.0.13, API 0.0.0, built Mon May 15 23:56:11 2017
        [path: C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\winext\pykd.dll]
    dbghelp: image 10.0.15063.137, API 10.0.6, built Thu Jan  1 01:00:00 1970
        [path: C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dbghelp.dll]
    ext: image 10.0.15063.137, API 1.0.0, built Thu Jan  1 01:00:00 1970
        [path: C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\winext\ext.dll]
    exts: image 10.0.15063.137, API 1.0.0, built Thu Jan  1 01:00:00 1970
        [path: C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\WINXP\exts.dll]
    kext: image 10.0.15063.137, API 1.0.0, built Thu Jan  1 01:00:00 1970
        [path: C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\winext\kext.dll]
    kdexts: image 10.0.15063.137, API 1.0.0, built Thu Jan  1 01:00:00 1970
        [path: C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\WINXP\kdexts.dll]
Closed Aug 25 at 9:16 AM by kernelnet
as double

comments

kernelnet wrote Aug 21 at 8:29 AM

well known problem:
see 14089

bchesley wrote Aug 22 at 8:04 AM

Ok, thanks for answer and sorry for the duplicate.
I guess there's no planned fix for this then?

kernelnet wrote Aug 22 at 3:43 PM

I don't know how it may be fixed unfortunately. Maybe it will be fixed in the next windows kits releases.

wrote Aug 25 at 9:16 AM