DREW:
Thanks,
MM
>> xxxxx@winse.microsoft.com 2006-08-07 14:57 >>>
You can avoid this by using an explicit workspace (save a named
workspace or save one to a file, then open your workspace from the
file).
If you leave it to windbg to use implicit workspaces there’s a
workspace
switch when the target shuts down, from fully initialized to
kernel-unknown (since a different OS could boot). When the target
boots
up there’ll be a switch from kernel-unknown to fully initialized.
These
workspace changes can result in window/dock close/open as state is
restored, thus there can be window changes. There isn’t a way to stop
this since it’s the way workspace restore is supposed to work.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Monday, August 07, 2006 11:27 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] An extremely minor annoyance
DREW:
As long as we’re on the subject of windows on the taskbar (I think; I
didn’t read the whole thing), I have a request about which probably no
one else cares. Would the WinDbg team be willing to consider a change
to prevent recreating an open secondary dock window when the target
reboots? I realize that this is neurotic, but it drives me out of my
mind because it causes the windows on the task bar to appear in a
different order, and forces me to either adjust or start and restart
everything.
Thanks,
MM
>> xxxxx@winse.microsoft.com 2006-08-07 13:29 >>>
Thanks for the report. We’ve had other reports but we haven’t been
able
to isolate exactly what’s happening as we can’t cause the problem to
occur. When windbg is busy do you do anything else with the UI or
just
switch away? Our current theory is that for some reason the UI thread
blocks also and the system drops the window from the tray when windbg
stops responding. That shouldn’t happen unless you try certain extra
UI
operations when the debugging thread is busy.
If you notice a specific set of steps which reliably repro the problem
please let us know.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Sunday, August 06, 2006 10:50 AM
To: Kernel Debugging Interest List
Subject: [windbg] An extremely minor annoyance
I am debugging a client/server product (so two sessions of WinDBG on
my
dev machine). If when WinDBG indicates it is busy, I switch to
another
application, one of the two taskbar entries for WinDBG sometimes
disappears.
The session is still there and if I close the various windows covering
then click in the command window the taskbar entry returns. Note: it
does not do this consistently, but fairly often.
I figured the WinDBG team should know about this, but it should be low
on the priority to fix.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to windbg as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to windbg as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com