All,
For a research purpose, I am looking for old release of WinDbg, the
older the better. Could someone send me a copy or advice a link? Thank
you very much.
BR, Raymond
RAYMOND:
There’s a few links to older versions on the same download page as the
for the newest one.
>> xxxxx@intel.com >>>
All,
For a research purpose, I am looking for old release of WinDbg, the
older the better. Could someone send me a copy or advice a link? Thank
you very much.
BR, Raymond
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hello,
* On Fri, May 04, 2007 at 01:22:13PM -0400 Martin O’Brien wrote:
>>> xxxxx@intel.com >>>
All,> For a research purpose, I am looking for old release of WinDbg, the
> older the better. Could someone send me a copy or advice a link? Thank
> you very much.
I hope you do not want to have one of these “infamous” 5.xx versions.
(These are OLDER than even the WinDBG 1.xx versions; some of them were
extremely buggy up to the point where they were absolutely unusable.
Microsoft decided to start it all over, starting counting with 1.xx
again.)
If you want one of them, you need a Platform SDK from the NT 4.0 days.
Regards,
Spiro.
–
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/
“Spiro Trikaliotis” wrote in message
news:xxxxx@windbg…
> I hope you do not want to have one of these “infamous” 5.xx versions.
> (These are OLDER than even the WinDBG 1.xx versions; some of them were
> extremely buggy up to the point where they were absolutely unusable.
> Microsoft decided to start it all over, starting counting with 1.xx
> again.)
>
Actually the initial “start over” was the worst. Having used WinDBG from
NT 3.5 it was flaky but predictable, then went to total crap, the started
getting better, up to the new user interface where it is back to flaky.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
Hello Don,
* On Sat, May 05, 2007 at 06:55:23AM -0400 Don Burn wrote:
Actually the initial “start over” was the worst. Having used WinDBG from
NT 3.5 it was flaky but predictable, then went to total crap, the started
getting better, up to the new user interface where it is back to flaky.
well, I started with WinDBG with NT4, somewhere between SP3 and SP5,
thus, my experience is not as long as yours, but:
With WinDBG 5.xx, I had had great luck in finding a version which worked
“almost” reliably. Yes, there were some problems, I was not allowed to
enter some commands, but most of WinDBG was working, more or less.
Anyway, I have had collegues which tried to run WinDBG, and they did not
succeed. WinDBG did not want to establish any connection to the other
side, or it crashed, or - it failed in numerous ways. “By accident”, we
found that we were using different versions of it. It helped my
collegues to use exactly the version of WinDBG I used - no version
before, no version after that specific one.
Yes, you are right, the start over was problematic, too. Nevertheless,
one could really see things improving almost always. There were not so
much steps backwards as were before (the new) WinDBG 1.xx.
The new UI is something for itself. I did not like it very much in the
first place. Now, I’ve got used to it. In fact, I do not remember the
older interface, so, I am not sure how I would rate it now.
Nevertheless, the new UI is somehow problematic if I want to arrange my
Windows as I like them. I often have to try more than once before it
works as I want to. I did not have any real problems with the UI for
some versions of WinDBG, however.
So, overall, I still believe the new WinDBG is much better than the old
one ever was. In fact, it is usable - and that is most important.
Additionally, the team is very responsive and seems to be thankful for
any bug report. This is something that is not always the case with any
software.
But I tend to digress from the topic, don’t I?
Regards,
Spiro.
–
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/
“Spiro Trikaliotis” wrote in message
news:xxxxx@windbg…
> The new UI is something for itself. I did not like it very much in the
> first place. Now, I’ve got used to it. In fact, I do not remember the
> older interface, so, I am not sure how I would rate it now.
> Nevertheless, the new UI is somehow problematic if I want to arrange my
> Windows as I like them. I often have to try more than once before it
> works as I want to. I did not have any real problems with the UI for
> some versions of WinDBG, however.
>
My biggest problem with the new WinDBG is the UI. My four favorites are:
1. I have the “disappearing window” syndrome at least twice a day, this
is where WinDBG disappears from the task bar, and if you are like me and
have a lot of applications up, trying to find WinDBG is a royal pain.
2. Another variant of this is the disappearing main window, I.E. the
window with the menus etc disappears off the desktop, this one keeps it on
the taskbar so the solution is to maximize the window which redisplays it,
then shrink it down so it is the size you want.
3. On the opposite end of the scale you get the command window as a
seperate taskbar item. So there are to task bar entries, considering I am
debugging a distruted file system at the moment and have 3 WinDBG’s up all
the time, having 6 items on the task bar is a pain.
4. Finally, the “flying scroll” on the source windows. I break in to set
a breakpoint, and scroll to the place where I want it, around 30% of the
time something happens such as when I go to select the line, the window
scrolls extremely quickly back to the place it was prior to my scrolling.
Now considering these are big files, this is very unfriendly. This one
could be me, but I haven’t figured out the magic to stop it.
Overall, my biggest complaint with the new UI, is that it gets in the way
(the four items above are some of the biggies). For a debugger getting in
the way or making you think about the debugger rather than the bug is the
cardinal sin. I have managed teams where I wrote and owned debugger’s and
I would never have accepted something like this.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
Many thanks for all responses. Now I am trying to build a whole picture.
Please correct me if any wrong.
- Most of current fundamental debug support (kd engine and dbgss) was
built in NTOS from birth of NT 3.1. And a console UI application,
NTSD.exe, was developed at same time. Until Windows XP, NTSD.exe exists
in system32 folder by default. But Vista removed it (what a pity!). - I guess the first series of WinDbg and KD was developed almost same
with NTSD and it was available though support tool package, such like
Windows NT/2000 Support Tools CD. This series grew to at least version 5
at about year 2000. - In about 2000 or 2001, development of WinDbg experienced a big change
and version no was reset. Most noticeable change is new WinDbg is built
on COM, previous generations should be not.
Any comment and completion will be appreciated.
BR, Raymond
“Zhang, Raymond” wrote:
Most noticeable change is new WinDbg is built on COM,
previous generations should be not.
WinDbg is not built on COM. The debug engine (DbgEng.dll) does have
a COM-like interface but it does not depend on the COM runtime (ole32.dll).
–
This posting is provided “AS IS” with no warranties, and confers no
rights.
Please report bugs to xxxxx@microsoft.com. That’s the way to get someone to look at them and consider a fix. I look forward to your mail with repro steps for #1-3. #4 I can repro, and IIRC it’s a problem with the control class we use, rather than a debugger bug. A fix there is not likely any time soon. If your steps don’t involve switching focus off the source window or not having focus there in the first place, please send your steps for it as well since they’re different than mine.
Thanks,
Jason
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Saturday, May 05, 2007 5:36 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Old release of WinDbg
“Spiro Trikaliotis” wrote in message
news:xxxxx@windbg…
> The new UI is something for itself. I did not like it very much in the
> first place. Now, I’ve got used to it. In fact, I do not remember the
> older interface, so, I am not sure how I would rate it now.
> Nevertheless, the new UI is somehow problematic if I want to arrange my
> Windows as I like them. I often have to try more than once before it
> works as I want to. I did not have any real problems with the UI for
> some versions of WinDBG, however.
>
My biggest problem with the new WinDBG is the UI. My four favorites are:
1. I have the “disappearing window” syndrome at least twice a day, this
is where WinDBG disappears from the task bar, and if you are like me and
have a lot of applications up, trying to find WinDBG is a royal pain.
2. Another variant of this is the disappearing main window, I.E. the
window with the menus etc disappears off the desktop, this one keeps it on
the taskbar so the solution is to maximize the window which redisplays it,
then shrink it down so it is the size you want.
3. On the opposite end of the scale you get the command window as a
seperate taskbar item. So there are to task bar entries, considering I am
debugging a distruted file system at the moment and have 3 WinDBG’s up all
the time, having 6 items on the task bar is a pain.
4. Finally, the “flying scroll” on the source windows. I break in to set
a breakpoint, and scroll to the place where I want it, around 30% of the
time something happens such as when I go to select the line, the window
scrolls extremely quickly back to the place it was prior to my scrolling.
Now considering these are big files, this is very unfriendly. This one
could be me, but I haven’t figured out the magic to stop it.
Overall, my biggest complaint with the new UI, is that it gets in the way
(the four items above are some of the biggies). For a debugger getting in
the way or making you think about the debugger rather than the bug is the
cardinal sin. I have managed teams where I wrote and owned debugger’s and
I would never have accepted something like this.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
—
You are currently subscribed to windbg as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
#1: actually, this is a good thing. The in-box ntsd is constantly out of date and thus has known bugs, and lacks pretty much all the extensions that you’d care about. In other words, if you use the system32 ntsd, the frequent answer is to install the debugger package and use the latest bits instead. I’ve lost count of the number of bug reports on system32 where the answer was simply to install the latest package. This ignores all the folks who did install the latest debugger package and reported a ‘bug’ on ntsd because system32 was on the path before the latest debugger install.
Thanks,
Jason
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Zhang, Raymond
Sent: Saturday, May 05, 2007 8:13 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Old release of WinDbg
Many thanks for all responses. Now I am trying to build a whole picture.
Please correct me if any wrong.
- Most of current fundamental debug support (kd engine and dbgss) was
built in NTOS from birth of NT 3.1. And a console UI application,
NTSD.exe, was developed at same time. Until Windows XP, NTSD.exe exists
in system32 folder by default. But Vista removed it (what a pity!). - I guess the first series of WinDbg and KD was developed almost same
with NTSD and it was available though support tool package, such like
Windows NT/2000 Support Tools CD. This series grew to at least version 5
at about year 2000. - In about 2000 or 2001, development of WinDbg experienced a big change
and version no was reset. Most noticeable change is new WinDbg is built
on COM, previous generations should be not.
Any comment and completion will be appreciated.
BR, Raymond
You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Jason,
I’ve reported this on and off for over a year (I will not comment on
the responses). THERE ARE NO EASY REPRO STEPS, OR I WOULD NOT DO THAT ANY
MORE!!! I am using 3 WindDBG’s, a copy of Outlook Express, VS6,
and the latest WDK documentation, I toggle between windows (including
minimizing things), and “poof” WinDBG looses its mind or at least its GUI.
I refuse to use any docked Windows, since I find them worse than worthless,
which may contribute to this. By the way all of the first three happened
in a 90 minute debugging session this morning.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Jason Cunningham” wrote in message
news:xxxxx@windbg…
Please report bugs to xxxxx@microsoft.com. That’s the way to get
someone to look at them and consider a fix. I look forward to your mail
with repro steps for #1-3. #4 I can repro, and IIRC it’s a problem with
the control class we use, rather than a debugger bug. A fix there is not
likely any time soon. If your steps don’t involve switching focus off the
source window or not having focus there in the first place, please send
your steps for it as well since they’re different than mine.
Thanks,
Jason
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Saturday, May 05, 2007 5:36 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Old release of WinDbg
“Spiro Trikaliotis” wrote in message
news:xxxxx@windbg…
> The new UI is something for itself. I did not like it very much in the
> first place. Now, I’ve got used to it. In fact, I do not remember the
> older interface, so, I am not sure how I would rate it now.
> Nevertheless, the new UI is somehow problematic if I want to arrange my
> Windows as I like them. I often have to try more than once before it
> works as I want to. I did not have any real problems with the UI for
> some versions of WinDBG, however.
>
My biggest problem with the new WinDBG is the UI. My four favorites are:
1. I have the “disappearing window” syndrome at least twice a day, this
is where WinDBG disappears from the task bar, and if you are like me and
have a lot of applications up, trying to find WinDBG is a royal pain.
2. Another variant of this is the disappearing main window, I.E. the
window with the menus etc disappears off the desktop, this one keeps it on
the taskbar so the solution is to maximize the window which redisplays it,
then shrink it down so it is the size you want.
3. On the opposite end of the scale you get the command window as a
seperate taskbar item. So there are to task bar entries, considering I am
debugging a distruted file system at the moment and have 3 WinDBG’s up all
the time, having 6 items on the task bar is a pain.
4. Finally, the “flying scroll” on the source windows. I break in to set
a breakpoint, and scroll to the place where I want it, around 30% of the
time something happens such as when I go to select the line, the window
scrolls extremely quickly back to the place it was prior to my scrolling.
Now considering these are big files, this is very unfriendly. This one
could be me, but I haven’t figured out the magic to stop it.
Overall, my biggest complaint with the new UI, is that it gets in the way
(the four items above are some of the biggies). For a debugger getting in
the way or making you think about the debugger rather than the bug is the
cardinal sin. I have managed teams where I wrote and owned debugger’s and
I would never have accepted something like this.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
—
You are currently subscribed to windbg as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Then perhaps you could capture a dump and send it along? It’s doubtful from one dump after-the-fact that we’ll get something useful as I suspect we’ll need to look at the OS at some point here, but it is possible.
What would probably be more helpful would be to send along the workspace that runs into trouble the most frequently along with some basic info (multimon, what OS) so we can poke things around with as close to the same setup you have as we can get. I can’t guarantee you anything, but we would be happy to have a look.
You could either save the workspace to a file from windbg UI or just dump the entire registry (HKCU\Software\Microsoft\Windbg).
Thanks,
Jason
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, May 08, 2007 11:24 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Re:Old release of WinDbg
Jason,
I’ve reported this on and off for over a year (I will not comment on
the responses). THERE ARE NO EASY REPRO STEPS, OR I WOULD NOT DO THAT ANY
MORE!!! I am using 3 WindDBG’s, a copy of Outlook Express, VS6,
and the latest WDK documentation, I toggle between windows (including
minimizing things), and “poof” WinDBG looses its mind or at least its GUI.
I refuse to use any docked Windows, since I find them worse than worthless,
which may contribute to this. By the way all of the first three happened
in a 90 minute debugging session this morning.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Jason Cunningham” wrote in message
news:xxxxx@windbg…
Please report bugs to xxxxx@microsoft.com. That’s the way to get
someone to look at them and consider a fix. I look forward to your mail
with repro steps for #1-3. #4 I can repro, and IIRC it’s a problem with
the control class we use, rather than a debugger bug. A fix there is not
likely any time soon. If your steps don’t involve switching focus off the
source window or not having focus there in the first place, please send
your steps for it as well since they’re different than mine.
Thanks,
Jason
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Saturday, May 05, 2007 5:36 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Old release of WinDbg
“Spiro Trikaliotis” wrote in message
news:xxxxx@windbg…
> The new UI is something for itself. I did not like it very much in the
> first place. Now, I’ve got used to it. In fact, I do not remember the
> older interface, so, I am not sure how I would rate it now.
> Nevertheless, the new UI is somehow problematic if I want to arrange my
> Windows as I like them. I often have to try more than once before it
> works as I want to. I did not have any real problems with the UI for
> some versions of WinDBG, however.
>
My biggest problem with the new WinDBG is the UI. My four favorites are:
1. I have the “disappearing window” syndrome at least twice a day, this
is where WinDBG disappears from the task bar, and if you are like me and
have a lot of applications up, trying to find WinDBG is a royal pain.
2. Another variant of this is the disappearing main window, I.E. the
window with the menus etc disappears off the desktop, this one keeps it on
the taskbar so the solution is to maximize the window which redisplays it,
then shrink it down so it is the size you want.
3. On the opposite end of the scale you get the command window as a
seperate taskbar item. So there are to task bar entries, considering I am
debugging a distruted file system at the moment and have 3 WinDBG’s up all
the time, having 6 items on the task bar is a pain.
4. Finally, the “flying scroll” on the source windows. I break in to set
a breakpoint, and scroll to the place where I want it, around 30% of the
time something happens such as when I go to select the line, the window
scrolls extremely quickly back to the place it was prior to my scrolling.
Now considering these are big files, this is very unfriendly. This one
could be me, but I haven’t figured out the magic to stop it.
Overall, my biggest complaint with the new UI, is that it gets in the way
(the four items above are some of the biggies). For a debugger getting in
the way or making you think about the debugger rather than the bug is the
cardinal sin. I have managed teams where I wrote and owned debugger’s and
I would never have accepted something like this.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
—
I can confirm all of the behavior that Don reported, except the issue
involving a source window, and I use docked windows. I would add the
problem of clicking on WinDbg on the taskbar and nothing appears without
actually taking restore. Also, while on the subject of WinDbg, docking
windows, and the taskbar, the way the docking window get closed and
reopened during boot drives me out of my mind, because it rearranges
things on the taskbar, which sucks if you have a lot of windows open.
This one is pretty clearly a design choice, not a problem, and probably
only even occurs to neurotic people like myself, but I thought I’d just
throw it in while on the subject. I would also throw in how the release
notes file always contains teasers for new commands or additions to old
commands that generally are not documented. This is irritating.
Neither of my first two additions nor Don’s issues are probably the end
of the world, but they are nevertheless irritating problems in, for most
of us, our primary tool. I find them particularly irritating because,
to an outsider, it is kind of mystery why they exist at all, as a lot of
this behavior is automatically handled by Windows, unless one goes out
of his or her way to do something different. For example, I noticed
this earlier this morning in the release notes file that came with the
most recent WinDbg package .
* Windbg does not draw it’s window frames well on Windows Vista
when running Aero Glass.
I think Don’s statement about the UI being screwy is more than fair.
What follows is a personal statement about why I think WinDbg is worth
improving.
WinDbg is free, and that, in my mind, is the cause of these types of
problems, because they don’t exist, in my experience, in other Microsoft
products. While this is very understandable, if it is in fact what is
going on, I think it is a mistake. A lot of talk goes on here about
what can be done to improve stability of production drivers. Some of
the solutions are, in my opinion, rather extreme, and, should they not
be your personal cup of tea, have somewhat of a vaguely facist feel to
them, as it were. I don’t mean that in a conspiracy/monopoly theory
sort of way, or other nonsense of that sort. I just mean, some of these
things that are really being pushed hard, at the moment, have very
obvious problems that aren’t exactly highlighted. Microsoft will fix
them; they always do. I have no doubt, that DTM, for example, will
someday provide legitimate value to some developers. Presently, the
situation doesn’t need any comment. I can’t say that I have any idea of
what the deal with Driver Signing is, because it seems like it should be
straightforward, but most definitely, at present, is not.
The most significant thing that I think gets more or less left out of
the information and advice is that almost all of these solutions, though
not without merit, at least initially present a huge learning curve that
involves changing the set of practices and pecedilos that make each of
us an individual, for better or worse. WPP, in my mind, is the a good
example of this. Apparently, it can do your taxes for you in a virtual,
visual, object oriented, internet aware way that meets the needs of
developers of robust, mission-critical software with a short time to
market; that is, if you are willing to change your build procedures and
the way printf statements have been terminated since the dawn of time,
possibly among other things. Frankly, I don’t know what else, may be
nothing, because I know nothing else about WPP, because I stopped
looking as soon as heard about ‘\n’ thing, also for better or worse. In
my opinion, that’s a pretty common response, even among good,
responsible developers.
So, here’s where I’m going with all of this. In my opinion, improving
WinDbg would be the single best thing that could be done toward the goal
of improving system stability. Basically, this would start with a
complete rewrite of the documentation that featured documentation of all
the extensions (whoever may or may not have written them); an index
created by a human being with enough knowledge of the subject to provide
alternatives to either the ‘0’ or ‘500’ hits that most searches seem to
produce; a set of tables or other documents that grouped extensions by
category (i. e. - these are the extensions for virtual memory
management), taking in to account the (formidable) problem of most
commands being two or three letters long. Improvements to the UI would
be nice, and there some extensions that desperately need to get fixed
(!vtop and !ptov come to mind), but realization of the wishes expressed
in the previous sentence would make me positively giddy. Should any of
this materialize, it will not by a long shot produce obviously
significant improvements in stability, but nothing that doesn’t restrict
who can develop drivers is going to do produce results of that
magnitude.
While it certainly is true that, at best, we are a tiny group of
developers, and one with wants that are largely orthogonal to those of
the incomparably larger user mode community, another valid way of
looking at it is that, according to Microsoft, out of however many
bluescreens that have occurred in the time it has taken me to write
this, we are largely responsible for the vast majority of them. I agree
100% with the Microsoft figures.
I may be completely incorrect about allocating some additional
resources to WinDbg being beneficial, but it seems to me that
reassigning a truly small handful of people from solutions that have the
same goal - say Driver Signing, DTM and WPP - is an experiment well
worth running.
mm
>> xxxxx@acm.org 2007-05-08 14:24 >>>
Jason,
I’ve reported this on and off for over a year (I will not comment
on
the responses). THERE ARE NO EASY REPRO STEPS, OR I WOULD NOT DO THAT
ANY
MORE!!! I am using 3 WindDBG’s, a copy of Outlook Express,
VS6,
and the latest WDK documentation, I toggle between windows (including
minimizing things), and “poof” WinDBG looses its mind or at least its
GUI.
I refuse to use any docked Windows, since I find them worse than
worthless,
which may contribute to this. By the way all of the first three
happened
in a 90 minute debugging session this morning.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Jason Cunningham” wrote in message
news:xxxxx@windbg…
Please report bugs to xxxxx@microsoft.com. That’s the way to get
someone to look at them and consider a fix. I look forward to your
mail
with repro steps for #1-3. #4 I can repro, and IIRC it’s a problem
with
the control class we use, rather than a debugger bug. A fix there is
not
likely any time soon. If your steps don’t involve switching focus off
the
source window or not having focus there in the first place, please send
your steps for it as well since they’re different than mine.
Thanks,
Jason
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Saturday, May 05, 2007 5:36 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Old release of WinDbg
“Spiro Trikaliotis” wrote in message
news:xxxxx@windbg…
> The new UI is something for itself. I did not like it very much in
the
> first place. Now, I’ve got used to it. In fact, I do not remember
the
> older interface, so, I am not sure how I would rate it now.
> Nevertheless, the new UI is somehow problematic if I want to arrange
my
> Windows as I like them. I often have to try more than once before it
> works as I want to. I did not have any real problems with the UI for
> some versions of WinDBG, however.
>
My biggest problem with the new WinDBG is the UI. My four favorites
are:
1. I have the “disappearing window” syndrome at least twice a day,
this
is where WinDBG disappears from the task bar, and if you are like me
and
have a lot of applications up, trying to find WinDBG is a royal pain.
2. Another variant of this is the disappearing main window, I.E. the
window with the menus etc disappears off the desktop, this one keeps it
on
the taskbar so the solution is to maximize the window which redisplays
it,
then shrink it down so it is the size you want.
3. On the opposite end of the scale you get the command window as a
seperate taskbar item. So there are to task bar entries, considering I
am
debugging a distruted file system at the moment and have 3 WinDBG’s up
all
the time, having 6 items on the task bar is a pain.
4. Finally, the “flying scroll” on the source windows. I break in to
set
a breakpoint, and scroll to the place where I want it, around 30% of
the
time something happens such as when I go to select the line, the
window
scrolls extremely quickly back to the place it was prior to my
scrolling.
Now considering these are big files, this is very unfriendly. This
one
could be me, but I haven’t figured out the magic to stop it.
Overall, my biggest complaint with the new UI, is that it gets in the
way
(the four items above are some of the biggies). For a debugger getting
in
the way or making you think about the debugger rather than the bug is
the
cardinal sin. I have managed teams where I wrote and owned debugger’s
and
I would never have accepted something like this.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
—
You are currently subscribed to windbg as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: xxxxx@evitechnology.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I’m certainly not disagreeing with Don’s assertion that the GUI is not as good as it could be. It isn’t, and that’s a simple fact. I truly believe that Don has these problems exactly as frequently and irritatingly as he says. The problem I have, however, is that if I can’t make a bug happen, I generally can’t get it fixed.
Regarding Vista - we do pretty much use standard controls. Aero does some things differently in terms of how it reports metrics among other things which causes some problems.
On the relnotes: yes, that’s not nice. We’re trying to get that fixed by getting more doc writing resources. We’ve been operating under the theory that a small amount of poor information is better than nothing at all. This is NOT a guarantee, but we hope to have that problem at least solved for our next external release.
Thanks,
Jason
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Wednesday, May 09, 2007 12:57 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Re:Old release of WinDbg
I can confirm all of the behavior that Don reported, except the issue
involving a source window, and I use docked windows. I would add the
problem of clicking on WinDbg on the taskbar and nothing appears without
actually taking restore. Also, while on the subject of WinDbg, docking
windows, and the taskbar, the way the docking window get closed and
reopened during boot drives me out of my mind, because it rearranges
things on the taskbar, which sucks if you have a lot of windows open.
This one is pretty clearly a design choice, not a problem, and probably
only even occurs to neurotic people like myself, but I thought I’d just
throw it in while on the subject. I would also throw in how the release
notes file always contains teasers for new commands or additions to old
commands that generally are not documented. This is irritating.
Neither of my first two additions nor Don’s issues are probably the end
of the world, but they are nevertheless irritating problems in, for most
of us, our primary tool. I find them particularly irritating because,
to an outsider, it is kind of mystery why they exist at all, as a lot of
this behavior is automatically handled by Windows, unless one goes out
of his or her way to do something different. For example, I noticed
this earlier this morning in the release notes file that came with the
most recent WinDbg package .
* Windbg does not draw it’s window frames well on Windows Vista
when running Aero Glass.
I think Don’s statement about the UI being screwy is more than fair.
What follows is a personal statement about why I think WinDbg is worth
improving.
WinDbg is free, and that, in my mind, is the cause of these types of
problems, because they don’t exist, in my experience, in other Microsoft
products. While this is very understandable, if it is in fact what is
going on, I think it is a mistake. A lot of talk goes on here about
what can be done to improve stability of production drivers. Some of
the solutions are, in my opinion, rather extreme, and, should they not
be your personal cup of tea, have somewhat of a vaguely facist feel to
them, as it were. I don’t mean that in a conspiracy/monopoly theory
sort of way, or other nonsense of that sort. I just mean, some of these
things that are really being pushed hard, at the moment, have very
obvious problems that aren’t exactly highlighted. Microsoft will fix
them; they always do. I have no doubt, that DTM, for example, will
someday provide legitimate value to some developers. Presently, the
situation doesn’t need any comment. I can’t say that I have any idea of
what the deal with Driver Signing is, because it seems like it should be
straightforward, but most definitely, at present, is not.
The most significant thing that I think gets more or less left out of
the information and advice is that almost all of these solutions, though
not without merit, at least initially present a huge learning curve that
involves changing the set of practices and pecedilos that make each of
us an individual, for better or worse. WPP, in my mind, is the a good
example of this. Apparently, it can do your taxes for you in a virtual,
visual, object oriented, internet aware way that meets the needs of
developers of robust, mission-critical software with a short time to
market; that is, if you are willing to change your build procedures and
the way printf statements have been terminated since the dawn of time,
possibly among other things. Frankly, I don’t know what else, may be
nothing, because I know nothing else about WPP, because I stopped
looking as soon as heard about ‘\n’ thing, also for better or worse. In
my opinion, that’s a pretty common response, even among good,
responsible developers.
So, here’s where I’m going with all of this. In my opinion, improving
WinDbg would be the single best thing that could be done toward the goal
of improving system stability. Basically, this would start with a
complete rewrite of the documentation that featured documentation of all
the extensions (whoever may or may not have written them); an index
created by a human being with enough knowledge of the subject to provide
alternatives to either the ‘0’ or ‘500’ hits that most searches seem to
produce; a set of tables or other documents that grouped extensions by
category (i. e. - these are the extensions for virtual memory
management), taking in to account the (formidable) problem of most
commands being two or three letters long. Improvements to the UI would
be nice, and there some extensions that desperately need to get fixed
(!vtop and !ptov come to mind), but realization of the wishes expressed
in the previous sentence would make me positively giddy. Should any of
this materialize, it will not by a long shot produce obviously
significant improvements in stability, but nothing that doesn’t restrict
who can develop drivers is going to do produce results of that
magnitude.
While it certainly is true that, at best, we are a tiny group of
developers, and one with wants that are largely orthogonal to those of
the incomparably larger user mode community, another valid way of
looking at it is that, according to Microsoft, out of however many
bluescreens that have occurred in the time it has taken me to write
this, we are largely responsible for the vast majority of them. I agree
100% with the Microsoft figures.
I may be completely incorrect about allocating some additional
resources to WinDbg being beneficial, but it seems to me that
reassigning a truly small handful of people from solutions that have the
same goal - say Driver Signing, DTM and WPP - is an experiment well
worth running.
mm
>> xxxxx@acm.org 2007-05-08 14:24 >>>
Jason,
I’ve reported this on and off for over a year (I will not comment
on
the responses). THERE ARE NO EASY REPRO STEPS, OR I WOULD NOT DO THAT
ANY
MORE!!! I am using 3 WindDBG’s, a copy of Outlook Express,
VS6,
and the latest WDK documentation, I toggle between windows (including
minimizing things), and “poof” WinDBG looses its mind or at least its
GUI.
I refuse to use any docked Windows, since I find them worse than
worthless,
which may contribute to this. By the way all of the first three
happened
in a 90 minute debugging session this morning.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Jason Cunningham” wrote in message
news:xxxxx@windbg…
Please report bugs to xxxxx@microsoft.com. That’s the way to get
someone to look at them and consider a fix. I look forward to your
mail
with repro steps for #1-3. #4 I can repro, and IIRC it’s a problem
with
the control class we use, rather than a debugger bug. A fix there is
not
likely any time soon. If your steps don’t involve switching focus off
the
source window or not having focus there in the first place, please send
your steps for it as well since they’re different than mine.
Thanks,
Jason
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Saturday, May 05, 2007 5:36 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Old release of WinDbg
“Spiro Trikaliotis” wrote in message
news:xxxxx@windbg…
> The new UI is something for itself. I did not like it very much in
the
> first place. Now, I’ve got used to it. In fact, I do not remember
the
> older interface, so, I am not sure how I would rate it now.
> Nevertheless, the new UI is somehow problematic if I want to arrange
my
> Windows as I like them. I often have to try more than once before it
> works as I want to. I did not have any real problems with the UI for
> some versions of WinDBG, however.
>
My biggest problem with the new WinDBG is the UI. My four favorites
are:
1. I have the “disappearing window” syndrome at least twice a day,
this
is where WinDBG disappears from the task bar, and if you are like me
and
have a lot of applications up, trying to find WinDBG is a royal pain.
2. Another variant of this is the disappearing main window, I.E. the
window with the menus etc disappears off the desktop, this one keeps it
on
the taskbar so the solution is to maximize the window which redisplays
it,
then shrink it down so it is the size you want.
3. On the opposite end of the scale you get the command window as a
seperate taskbar item. So there are to task bar entries, considering I
am
debugging a distruted file system at the moment and have 3 WinDBG’s up
all
the time, having 6 items on the task bar is a pain.
4. Finally, the “flying scroll” on the source windows. I break in to
set
a breakpoint, and scroll to the place where I want it, around 30% of
the
time something happens such as when I go to select the line, the
window
scrolls extremely quickly back to the place it was prior to my
scrolling.
Now considering these are big files, this is very unfriendly. This
one
could be me, but I haven’t figured out the magic to stop it.
Overall, my biggest complaint with the new UI, is that it gets in the
way
(the four items above are some of the biggies). For a debugger getting
in
the way or making you think about the debugger rather than the bug is
the
cardinal sin. I have managed teams where I wrote and owned debugger’s
and
I would never have accepted something like this.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
Jason,
I will collect the info you asked for and send it to you (hopefully
before WinHEC but things are piling up). Note: I just use the default
workspace for all three instances (they are debugging the same driver).
Otherwise the system is XP SP2 with the all the updates applied running on
a rather old workstation (dual processor 450MHz P2 with 1GB of memory).
Two of the sessions are serial port and the third is 1394 (though I have
seen this with two 1394 sessions also).
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Jason Cunningham” wrote in message
news:xxxxx@windbg…
I’m certainly not disagreeing with Don’s assertion that the GUI is not as
good as it could be. It isn’t, and that’s a simple fact. I truly believe
that Don has these problems exactly as frequently and irritatingly as he
says. The problem I have, however, is that if I can’t make a bug happen, I
generally can’t get it fixed.
Regarding Vista - we do pretty much use standard controls. Aero does some
things differently in terms of how it reports metrics among other things
which causes some problems.
On the relnotes: yes, that’s not nice. We’re trying to get that fixed by
getting more doc writing resources. We’ve been operating under the theory
that a small amount of poor information is better than nothing at all.
This is NOT a guarantee, but we hope to have that problem at least solved
for our next external release.
Thanks,
Jason
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Wednesday, May 09, 2007 12:57 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Re:Old release of WinDbg
I can confirm all of the behavior that Don reported, except the issue
involving a source window, and I use docked windows. I would add the
problem of clicking on WinDbg on the taskbar and nothing appears without
actually taking restore. Also, while on the subject of WinDbg, docking
windows, and the taskbar, the way the docking window get closed and
reopened during boot drives me out of my mind, because it rearranges
things on the taskbar, which sucks if you have a lot of windows open.
This one is pretty clearly a design choice, not a problem, and probably
only even occurs to neurotic people like myself, but I thought I’d just
throw it in while on the subject. I would also throw in how the release
notes file always contains teasers for new commands or additions to old
commands that generally are not documented. This is irritating.
Neither of my first two additions nor Don’s issues are probably the end
of the world, but they are nevertheless irritating problems in, for most
of us, our primary tool. I find them particularly irritating because,
to an outsider, it is kind of mystery why they exist at all, as a lot of
this behavior is automatically handled by Windows, unless one goes out
of his or her way to do something different. For example, I noticed
this earlier this morning in the release notes file that came with the
most recent WinDbg package .
* Windbg does not draw it’s window frames well on Windows Vista
when running Aero Glass.
I think Don’s statement about the UI being screwy is more than fair.
What follows is a personal statement about why I think WinDbg is worth
improving.
WinDbg is free, and that, in my mind, is the cause of these types of
problems, because they don’t exist, in my experience, in other Microsoft
products. While this is very understandable, if it is in fact what is
going on, I think it is a mistake. A lot of talk goes on here about
what can be done to improve stability of production drivers. Some of
the solutions are, in my opinion, rather extreme, and, should they not
be your personal cup of tea, have somewhat of a vaguely facist feel to
them, as it were. I don’t mean that in a conspiracy/monopoly theory
sort of way, or other nonsense of that sort. I just mean, some of these
things that are really being pushed hard, at the moment, have very
obvious problems that aren’t exactly highlighted. Microsoft will fix
them; they always do. I have no doubt, that DTM, for example, will
someday provide legitimate value to some developers. Presently, the
situation doesn’t need any comment. I can’t say that I have any idea of
what the deal with Driver Signing is, because it seems like it should be
straightforward, but most definitely, at present, is not.
The most significant thing that I think gets more or less left out of
the information and advice is that almost all of these solutions, though
not without merit, at least initially present a huge learning curve that
involves changing the set of practices and pecedilos that make each of
us an individual, for better or worse. WPP, in my mind, is the a good
example of this. Apparently, it can do your taxes for you in a virtual,
visual, object oriented, internet aware way that meets the needs of
developers of robust, mission-critical software with a short time to
market; that is, if you are willing to change your build procedures and
the way printf statements have been terminated since the dawn of time,
possibly among other things. Frankly, I don’t know what else, may be
nothing, because I know nothing else about WPP, because I stopped
looking as soon as heard about ‘\n’ thing, also for better or worse. In
my opinion, that’s a pretty common response, even among good,
responsible developers.
So, here’s where I’m going with all of this. In my opinion, improving
WinDbg would be the single best thing that could be done toward the goal
of improving system stability. Basically, this would start with a
complete rewrite of the documentation that featured documentation of all
the extensions (whoever may or may not have written them); an index
created by a human being with enough knowledge of the subject to provide
alternatives to either the ‘0’ or ‘500’ hits that most searches seem to
produce; a set of tables or other documents that grouped extensions by
category (i. e. - these are the extensions for virtual memory
management), taking in to account the (formidable) problem of most
commands being two or three letters long. Improvements to the UI would
be nice, and there some extensions that desperately need to get fixed
(!vtop and !ptov come to mind), but realization of the wishes expressed
in the previous sentence would make me positively giddy. Should any of
this materialize, it will not by a long shot produce obviously
significant improvements in stability, but nothing that doesn’t restrict
who can develop drivers is going to do produce results of that
magnitude.
While it certainly is true that, at best, we are a tiny group of
developers, and one with wants that are largely orthogonal to those of
the incomparably larger user mode community, another valid way of
looking at it is that, according to Microsoft, out of however many
bluescreens that have occurred in the time it has taken me to write
this, we are largely responsible for the vast majority of them. I agree
100% with the Microsoft figures.
I may be completely incorrect about allocating some additional
resources to WinDbg being beneficial, but it seems to me that
reassigning a truly small handful of people from solutions that have the
same goal - say Driver Signing, DTM and WPP - is an experiment well
worth running.
mm
>>> xxxxx@acm.org 2007-05-08 14:24 >>>
Jason,
I’ve reported this on and off for over a year (I will not comment
on
the responses). THERE ARE NO EASY REPRO STEPS, OR I WOULD NOT DO THAT
ANY
MORE!!! I am using 3 WindDBG’s, a copy of Outlook Express,
VS6,
and the latest WDK documentation, I toggle between windows (including
minimizing things), and “poof” WinDBG looses its mind or at least its
GUI.
I refuse to use any docked Windows, since I find them worse than
worthless,
which may contribute to this. By the way all of the first three
happened
in a 90 minute debugging session this morning.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Jason Cunningham” wrote in message
news:xxxxx@windbg…
Please report bugs to xxxxx@microsoft.com. That’s the way to get
someone to look at them and consider a fix. I look forward to your
mail
with repro steps for #1-3. #4 I can repro, and IIRC it’s a problem
with
the control class we use, rather than a debugger bug. A fix there is
not
likely any time soon. If your steps don’t involve switching focus off
the
source window or not having focus there in the first place, please send
your steps for it as well since they’re different than mine.
Thanks,
Jason
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Saturday, May 05, 2007 5:36 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Old release of WinDbg
“Spiro Trikaliotis” wrote in message
news:xxxxx@windbg…
> The new UI is something for itself. I did not like it very much in
the
> first place. Now, I’ve got used to it. In fact, I do not remember
the
> older interface, so, I am not sure how I would rate it now.
> Nevertheless, the new UI is somehow problematic if I want to arrange
my
> Windows as I like them. I often have to try more than once before it
> works as I want to. I did not have any real problems with the UI for
> some versions of WinDBG, however.
>
My biggest problem with the new WinDBG is the UI. My four favorites
are:
1. I have the “disappearing window” syndrome at least twice a day,
this
is where WinDBG disappears from the task bar, and if you are like me
and
have a lot of applications up, trying to find WinDBG is a royal pain.
2. Another variant of this is the disappearing main window, I.E. the
window with the menus etc disappears off the desktop, this one keeps it
on
the taskbar so the solution is to maximize the window which redisplays
it,
then shrink it down so it is the size you want.
3. On the opposite end of the scale you get the command window as a
seperate taskbar item. So there are to task bar entries, considering I
am
debugging a distruted file system at the moment and have 3 WinDBG’s up
all
the time, having 6 items on the task bar is a pain.
4. Finally, the “flying scroll” on the source windows. I break in to
set
a breakpoint, and scroll to the place where I want it, around 30% of
the
time something happens such as when I go to select the line, the
window
scrolls extremely quickly back to the place it was prior to my
scrolling.
Now considering these are big files, this is very unfriendly. This
one
could be me, but I haven’t figured out the magic to stop it.
Overall, my biggest complaint with the new UI, is that it gets in the
way
(the four items above are some of the biggies). For a debugger getting
in
the way or making you think about the debugger rather than the bug is
the
cardinal sin. I have managed teams where I wrote and owned debugger’s
and
I would never have accepted something like this.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
rant mode on
well windbgging is not my fort but i do use windbg a lot especially
when i want to
attach to a chain of debuggers
>>>
The problem I have, however, is that if I can’t make a bug happen, I
generally can’t get it fixed.
>>>
like you say many of these gui getting insane and turning the one who
is windbgging psychic are infact not reproducible
they simply turn up in an unfortuante moment when you wanted it to be
perfect and hoped and prayed it doesnt screw up (it will screw up
exactly at that instance making you scream ##%#*%#&^% )
few days ago i was having a chain of ollydbg->ollydbg -> debugging
calc.exe (i was testing a plugin of ollydbg for some acute non
reproducible problem of infinite looping or hanging) and i attached
the primary ollydbg to windbg to check where it is looping infinitely
i narrowed down a place set a few breakpoint hit g
one of my break points hit and the gui was looking extremely good i
disabled a few breakpoints stepped a few executions set few new
breakpoints and i hit f5 on disassembly window
and the gui went insane at this point the disassembly window simply
didnt have the topbar it was invisible hiding behind the toolbar the
registers window simply occupied half of the gui the memory window got
hidden behind the commandwindow and i cannot for the life of me either
restore them back to thier old position or do anything else i simply
end tasked the whole crap and went away screaming
yes they are pretty annoying when you least expect them and given the
nick name for windows os as clickety click this gui looks like it was
developed in some fifttenth world country with cruel stepmotherly
treatment
well rant mode off
yes infact there are pretty good improvements too especially compring
the versions from 3.5 to 7.5 7.5 seems to pretty fast
the annoying nags do you want to do you dont want to do you wish to
not wish to blah blah seems to have disassappeared for good
the stack trace seems to have improved in the sense it now doesnt keep
sprewing warning messages instead of working one simple warning and
then it deciphers stack with export symbols doesnt keep whining about
missing symbols
several commands like uf (thanks for the bug fix ) which now have
additional switches /c are making life easier when anlysing complex
calls
hopefully some fine day i pray the gui would get better and behave
like other microsoft products that are gui based
On 5/10/07, Jason Cunningham wrote:
> I’m certainly not disagreeing with Don’s assertion that the GUI is not as good as it could be. It isn’t, and that’s a simple fact. I truly believe that Don has these problems exactly as frequently and irritatingly as he says. The problem I have, however, is that if I can’t make a bug happen, I generally can’t get it fixed.
>
> Regarding Vista - we do pretty much use standard controls. Aero does some things differently in terms of how it reports metrics among other things which causes some problems.
>
> On the relnotes: yes, that’s not nice. We’re trying to get that fixed by getting more doc writing resources. We’ve been operating under the theory that a small amount of poor information is better than nothing at all. This is NOT a guarantee, but we hope to have that problem at least solved for our next external release.
>
> Thanks,
> Jason
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
> Sent: Wednesday, May 09, 2007 12:57 PM
> To: Kernel Debugging Interest List
> Subject: Re:[windbg] Re:Old release of WinDbg
>
> I can confirm all of the behavior that Don reported, except the issue
> involving a source window, and I use docked windows. I would add the
> problem of clicking on WinDbg on the taskbar and nothing appears without
> actually taking restore. Also, while on the subject of WinDbg, docking
> windows, and the taskbar, the way the docking window get closed and
> reopened during boot drives me out of my mind, because it rearranges
> things on the taskbar, which sucks if you have a lot of windows open.
> This one is pretty clearly a design choice, not a problem, and probably
> only even occurs to neurotic people like myself, but I thought I’d just
> throw it in while on the subject. I would also throw in how the release
> notes file always contains teasers for new commands or additions to old
> commands that generally are not documented. This is irritating.
>
> Neither of my first two additions nor Don’s issues are probably the end
> of the world, but they are nevertheless irritating problems in, for most
> of us, our primary tool. I find them particularly irritating because,
> to an outsider, it is kind of mystery why they exist at all, as a lot of
> this behavior is automatically handled by Windows, unless one goes out
> of his or her way to do something different. For example, I noticed
> this earlier this morning in the release notes file that came with the
> most recent WinDbg package .
>
> * Windbg does not draw it’s window frames well on Windows Vista
> when running Aero Glass.
>
> I think Don’s statement about the UI being screwy is more than fair.
>
> What follows is a personal statement about why I think WinDbg is worth
> improving.
>
> WinDbg is free, and that, in my mind, is the cause of these types of
> problems, because they don’t exist, in my experience, in other Microsoft
> products. While this is very understandable, if it is in fact what is
> going on, I think it is a mistake. A lot of talk goes on here about
> what can be done to improve stability of production drivers. Some of
> the solutions are, in my opinion, rather extreme, and, should they not
> be your personal cup of tea, have somewhat of a vaguely facist feel to
> them, as it were. I don’t mean that in a conspiracy/monopoly theory
> sort of way, or other nonsense of that sort. I just mean, some of these
> things that are really being pushed hard, at the moment, have very
> obvious problems that aren’t exactly highlighted. Microsoft will fix
> them; they always do. I have no doubt, that DTM, for example, will
> someday provide legitimate value to some developers. Presently, the
> situation doesn’t need any comment. I can’t say that I have any idea of
> what the deal with Driver Signing is, because it seems like it should be
> straightforward, but most definitely, at present, is not.
>
> The most significant thing that I think gets more or less left out of
> the information and advice is that almost all of these solutions, though
> not without merit, at least initially present a huge learning curve that
> involves changing the set of practices and pecedilos that make each of
> us an individual, for better or worse. WPP, in my mind, is the a good
> example of this. Apparently, it can do your taxes for you in a virtual,
> visual, object oriented, internet aware way that meets the needs of
> developers of robust, mission-critical software with a short time to
> market; that is, if you are willing to change your build procedures and
> the way printf statements have been terminated since the dawn of time,
> possibly among other things. Frankly, I don’t know what else, may be
> nothing, because I know nothing else about WPP, because I stopped
> looking as soon as heard about ‘\n’ thing, also for better or worse. In
> my opinion, that’s a pretty common response, even among good,
> responsible developers.
>
> So, here’s where I’m going with all of this. In my opinion, improving
> WinDbg would be the single best thing that could be done toward the goal
> of improving system stability. Basically, this would start with a
> complete rewrite of the documentation that featured documentation of all
> the extensions (whoever may or may not have written them); an index
> created by a human being with enough knowledge of the subject to provide
> alternatives to either the ‘0’ or ‘500’ hits that most searches seem to
> produce; a set of tables or other documents that grouped extensions by
> category (i. e. - these are the extensions for virtual memory
> management), taking in to account the (formidable) problem of most
> commands being two or three letters long. Improvements to the UI would
> be nice, and there some extensions that desperately need to get fixed
> (!vtop and !ptov come to mind), but realization of the wishes expressed
> in the previous sentence would make me positively giddy. Should any of
> this materialize, it will not by a long shot produce obviously
> significant improvements in stability, but nothing that doesn’t restrict
> who can develop drivers is going to do produce results of that
> magnitude.
>
> While it certainly is true that, at best, we are a tiny group of
> developers, and one with wants that are largely orthogonal to those of
> the incomparably larger user mode community, another valid way of
> looking at it is that, according to Microsoft, out of however many
> bluescreens that have occurred in the time it has taken me to write
> this, we are largely responsible for the vast majority of them. I agree
> 100% with the Microsoft figures.
>
> I may be completely incorrect about allocating some additional
> resources to WinDbg being beneficial, but it seems to me that
> reassigning a truly small handful of people from solutions that have the
> same goal - say Driver Signing, DTM and WPP - is an experiment well
> worth running.
>
> mm
>
>
>
> >>> xxxxx@acm.org 2007-05-08 14:24 >>>
> Jason,
>
> I’ve reported this on and off for over a year (I will not comment
> on
> the responses). THERE ARE NO EASY REPRO STEPS, OR I WOULD NOT DO THAT
> ANY
> MORE!!! I am using 3 WindDBG’s, a copy of Outlook Express,
> VS6,
> and the latest WDK documentation, I toggle between windows (including
> minimizing things), and “poof” WinDBG looses its mind or at least its
> GUI.
> I refuse to use any docked Windows, since I find them worse than
> worthless,
> which may contribute to this. By the way all of the first three
> happened
> in a 90 minute debugging session this morning.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
> “Jason Cunningham” wrote in message
> news:xxxxx@windbg…
> Please report bugs to xxxxx@microsoft.com. That’s the way to get
> someone to look at them and consider a fix. I look forward to your
> mail
> with repro steps for #1-3. #4 I can repro, and IIRC it’s a problem
> with
> the control class we use, rather than a debugger bug. A fix there is
> not
> likely any time soon. If your steps don’t involve switching focus off
> the
> source window or not having focus there in the first place, please send
>
> your steps for it as well since they’re different than mine.
>
> Thanks,
> Jason
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
> Sent: Saturday, May 05, 2007 5:36 AM
> To: Kernel Debugging Interest List
> Subject: Re:[windbg] Old release of WinDbg
>
>
> “Spiro Trikaliotis” wrote in message
> news:xxxxx@windbg…
> > The new UI is something for itself. I did not like it very much in
> the
> > first place. Now, I’ve got used to it. In fact, I do not remember
> the
> > older interface, so, I am not sure how I would rate it now.
> > Nevertheless, the new UI is somehow problematic if I want to arrange
> my
> > Windows as I like them. I often have to try more than once before it
> > works as I want to. I did not have any real problems with the UI for
> > some versions of WinDBG, however.
> >
> My biggest problem with the new WinDBG is the UI. My four favorites
> are:
>
> 1. I have the “disappearing window” syndrome at least twice a day,
> this
> is where WinDBG disappears from the task bar, and if you are like me
> and
> have a lot of applications up, trying to find WinDBG is a royal pain.
>
> 2. Another variant of this is the disappearing main window, I.E. the
> window with the menus etc disappears off the desktop, this one keeps it
> on
> the taskbar so the solution is to maximize the window which redisplays
> it,
> then shrink it down so it is the size you want.
>
> 3. On the opposite end of the scale you get the command window as a
> seperate taskbar item. So there are to task bar entries, considering I
> am
> debugging a distruted file system at the moment and have 3 WinDBG’s up
> all
> the time, having 6 items on the task bar is a pain.
>
> 4. Finally, the “flying scroll” on the source windows. I break in to
> set
> a breakpoint, and scroll to the place where I want it, around 30% of
> the
> time something happens such as when I go to select the line, the
> window
> scrolls extremely quickly back to the place it was prior to my
> scrolling.
> Now considering these are big files, this is very unfriendly. This
> one
> could be me, but I haven’t figured out the magic to stop it.
>
> Overall, my biggest complaint with the new UI, is that it gets in the
> way
> (the four items above are some of the biggies). For a debugger getting
> in
> the way or making you think about the debugger rather than the bug is
> the
> cardinal sin. I have managed teams where I wrote and owned debugger’s
> and
> I would never have accepted something like this.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
> —
> You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Excellent, thanks Don. One other question: is TS involved?
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, May 09, 2007 3:28 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Re:Re:Old release of WinDbg
Jason,
I will collect the info you asked for and send it to you (hopefully
before WinHEC but things are piling up). Note: I just use the default
workspace for all three instances (they are debugging the same driver).
Otherwise the system is XP SP2 with the all the updates applied running on
a rather old workstation (dual processor 450MHz P2 with 1GB of memory).
Two of the sessions are serial port and the third is 1394 (though I have
seen this with two 1394 sessions also).
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Jason Cunningham” wrote in message
news:xxxxx@windbg…
I’m certainly not disagreeing with Don’s assertion that the GUI is not as
good as it could be. It isn’t, and that’s a simple fact. I truly believe
that Don has these problems exactly as frequently and irritatingly as he
says. The problem I have, however, is that if I can’t make a bug happen, I
generally can’t get it fixed.
Regarding Vista - we do pretty much use standard controls. Aero does some
things differently in terms of how it reports metrics among other things
which causes some problems.
On the relnotes: yes, that’s not nice. We’re trying to get that fixed by
getting more doc writing resources. We’ve been operating under the theory
that a small amount of poor information is better than nothing at all.
This is NOT a guarantee, but we hope to have that problem at least solved
for our next external release.
Thanks,
Jason
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Wednesday, May 09, 2007 12:57 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Re:Old release of WinDbg
I can confirm all of the behavior that Don reported, except the issue
involving a source window, and I use docked windows. I would add the
problem of clicking on WinDbg on the taskbar and nothing appears without
actually taking restore. Also, while on the subject of WinDbg, docking
windows, and the taskbar, the way the docking window get closed and
reopened during boot drives me out of my mind, because it rearranges
things on the taskbar, which sucks if you have a lot of windows open.
This one is pretty clearly a design choice, not a problem, and probably
only even occurs to neurotic people like myself, but I thought I’d just
throw it in while on the subject. I would also throw in how the release
notes file always contains teasers for new commands or additions to old
commands that generally are not documented. This is irritating.
Neither of my first two additions nor Don’s issues are probably the end
of the world, but they are nevertheless irritating problems in, for most
of us, our primary tool. I find them particularly irritating because,
to an outsider, it is kind of mystery why they exist at all, as a lot of
this behavior is automatically handled by Windows, unless one goes out
of his or her way to do something different. For example, I noticed
this earlier this morning in the release notes file that came with the
most recent WinDbg package .
* Windbg does not draw it’s window frames well on Windows Vista
when running Aero Glass.
I think Don’s statement about the UI being screwy is more than fair.
What follows is a personal statement about why I think WinDbg is worth
improving.
WinDbg is free, and that, in my mind, is the cause of these types of
problems, because they don’t exist, in my experience, in other Microsoft
products. While this is very understandable, if it is in fact what is
going on, I think it is a mistake. A lot of talk goes on here about
what can be done to improve stability of production drivers. Some of
the solutions are, in my opinion, rather extreme, and, should they not
be your personal cup of tea, have somewhat of a vaguely facist feel to
them, as it were. I don’t mean that in a conspiracy/monopoly theory
sort of way, or other nonsense of that sort. I just mean, some of these
things that are really being pushed hard, at the moment, have very
obvious problems that aren’t exactly highlighted. Microsoft will fix
them; they always do. I have no doubt, that DTM, for example, will
someday provide legitimate value to some developers. Presently, the
situation doesn’t need any comment. I can’t say that I have any idea of
what the deal with Driver Signing is, because it seems like it should be
straightforward, but most definitely, at present, is not.
The most significant thing that I think gets more or less left out of
the information and advice is that almost all of these solutions, though
not without merit, at least initially present a huge learning curve that
involves changing the set of practices and pecedilos that make each of
us an individual, for better or worse. WPP, in my mind, is the a good
example of this. Apparently, it can do your taxes for you in a virtual,
visual, object oriented, internet aware way that meets the needs of
developers of robust, mission-critical software with a short time to
market; that is, if you are willing to change your build procedures and
the way printf statements have been terminated since the dawn of time,
possibly among other things. Frankly, I don’t know what else, may be
nothing, because I know nothing else about WPP, because I stopped
looking as soon as heard about ‘\n’ thing, also for better or worse. In
my opinion, that’s a pretty common response, even among good,
responsible developers.
So, here’s where I’m going with all of this. In my opinion, improving
WinDbg would be the single best thing that could be done toward the goal
of improving system stability. Basically, this would start with a
complete rewrite of the documentation that featured documentation of all
the extensions (whoever may or may not have written them); an index
created by a human being with enough knowledge of the subject to provide
alternatives to either the ‘0’ or ‘500’ hits that most searches seem to
produce; a set of tables or other documents that grouped extensions by
category (i. e. - these are the extensions for virtual memory
management), taking in to account the (formidable) problem of most
commands being two or three letters long. Improvements to the UI would
be nice, and there some extensions that desperately need to get fixed
(!vtop and !ptov come to mind), but realization of the wishes expressed
in the previous sentence would make me positively giddy. Should any of
this materialize, it will not by a long shot produce obviously
significant improvements in stability, but nothing that doesn’t restrict
who can develop drivers is going to do produce results of that
magnitude.
While it certainly is true that, at best, we are a tiny group of
developers, and one with wants that are largely orthogonal to those of
the incomparably larger user mode community, another valid way of
looking at it is that, according to Microsoft, out of however many
bluescreens that have occurred in the time it has taken me to write
this, we are largely responsible for the vast majority of them. I agree
100% with the Microsoft figures.
I may be completely incorrect about allocating some additional
resources to WinDbg being beneficial, but it seems to me that
reassigning a truly small handful of people from solutions that have the
same goal - say Driver Signing, DTM and WPP - is an experiment well
worth running.
mm
>>> xxxxx@acm.org 2007-05-08 14:24 >>>
Jason,
I’ve reported this on and off for over a year (I will not comment
on
the responses). THERE ARE NO EASY REPRO STEPS, OR I WOULD NOT DO THAT
ANY
MORE!!! I am using 3 WindDBG’s, a copy of Outlook Express,
VS6,
and the latest WDK documentation, I toggle between windows (including
minimizing things), and “poof” WinDBG looses its mind or at least its
GUI.
I refuse to use any docked Windows, since I find them worse than
worthless,
which may contribute to this. By the way all of the first three
happened
in a 90 minute debugging session this morning.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Jason Cunningham” wrote in message
news:xxxxx@windbg…
Please report bugs to xxxxx@microsoft.com. That’s the way to get
someone to look at them and consider a fix. I look forward to your
mail
with repro steps for #1-3. #4 I can repro, and IIRC it’s a problem
with
the control class we use, rather than a debugger bug. A fix there is
not
likely any time soon. If your steps don’t involve switching focus off
the
source window or not having focus there in the first place, please send
your steps for it as well since they’re different than mine.
Thanks,
Jason
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Saturday, May 05, 2007 5:36 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Old release of WinDbg
“Spiro Trikaliotis” wrote in message
news:xxxxx@windbg…
> The new UI is something for itself. I did not like it very much in
the
> first place. Now, I’ve got used to it. In fact, I do not remember
the
> older interface, so, I am not sure how I would rate it now.
> Nevertheless, the new UI is somehow problematic if I want to arrange
my
> Windows as I like them. I often have to try more than once before it
> works as I want to. I did not have any real problems with the UI for
> some versions of WinDBG, however.
>
My biggest problem with the new WinDBG is the UI. My four favorites
are:
1. I have the “disappearing window” syndrome at least twice a day,
this
is where WinDBG disappears from the task bar, and if you are like me
and
have a lot of applications up, trying to find WinDBG is a royal pain.
2. Another variant of this is the disappearing main window, I.E. the
window with the menus etc disappears off the desktop, this one keeps it
on
the taskbar so the solution is to maximize the window which redisplays
it,
then shrink it down so it is the size you want.
3. On the opposite end of the scale you get the command window as a
seperate taskbar item. So there are to task bar entries, considering I
am
debugging a distruted file system at the moment and have 3 WinDBG’s up
all
the time, having 6 items on the task bar is a pain.
4. Finally, the “flying scroll” on the source windows. I break in to
set
a breakpoint, and scroll to the place where I want it, around 30% of
the
time something happens such as when I go to select the line, the
window
scrolls extremely quickly back to the place it was prior to my
scrolling.
Now considering these are big files, this is very unfriendly. This
one
could be me, but I haven’t figured out the magic to stop it.
Overall, my biggest complaint with the new UI, is that it gets in the
way
(the four items above are some of the biggies). For a debugger getting
in
the way or making you think about the debugger rather than the bug is
the
cardinal sin. I have managed teams where I wrote and owned debugger’s
and
I would never have accepted something like this.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
No there is no TS involved.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Jason Cunningham” wrote in message
news:xxxxx@windbg…
Excellent, thanks Don. One other question: is TS involved?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, May 09, 2007 3:28 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Re:Re:Old release of WinDbg
Jason,
I will collect the info you asked for and send it to you (hopefully
before WinHEC but things are piling up). Note: I just use the default
workspace for all three instances (they are debugging the same driver).
Otherwise the system is XP SP2 with the all the updates applied running on
a rather old workstation (dual processor 450MHz P2 with 1GB of memory).
Two of the sessions are serial port and the third is 1394 (though I have
seen this with two 1394 sessions also).
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Jason Cunningham” wrote in message
news:xxxxx@windbg…
I’m certainly not disagreeing with Don’s assertion that the GUI is not as
good as it could be. It isn’t, and that’s a simple fact. I truly believe
that Don has these problems exactly as frequently and irritatingly as he
says. The problem I have, however, is that if I can’t make a bug happen, I
generally can’t get it fixed.
Regarding Vista - we do pretty much use standard controls. Aero does some
things differently in terms of how it reports metrics among other things
which causes some problems.
On the relnotes: yes, that’s not nice. We’re trying to get that fixed by
getting more doc writing resources. We’ve been operating under the theory
that a small amount of poor information is better than nothing at all.
This is NOT a guarantee, but we hope to have that problem at least solved
for our next external release.
Thanks,
Jason
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Wednesday, May 09, 2007 12:57 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Re:Old release of WinDbg
I can confirm all of the behavior that Don reported, except the issue
involving a source window, and I use docked windows. I would add the
problem of clicking on WinDbg on the taskbar and nothing appears without
actually taking restore. Also, while on the subject of WinDbg, docking
windows, and the taskbar, the way the docking window get closed and
reopened during boot drives me out of my mind, because it rearranges
things on the taskbar, which sucks if you have a lot of windows open.
This one is pretty clearly a design choice, not a problem, and probably
only even occurs to neurotic people like myself, but I thought I’d just
throw it in while on the subject. I would also throw in how the release
notes file always contains teasers for new commands or additions to old
commands that generally are not documented. This is irritating.
Neither of my first two additions nor Don’s issues are probably the end
of the world, but they are nevertheless irritating problems in, for most
of us, our primary tool. I find them particularly irritating because,
to an outsider, it is kind of mystery why they exist at all, as a lot of
this behavior is automatically handled by Windows, unless one goes out
of his or her way to do something different. For example, I noticed
this earlier this morning in the release notes file that came with the
most recent WinDbg package .
* Windbg does not draw it’s window frames well on Windows Vista
when running Aero Glass.
I think Don’s statement about the UI being screwy is more than fair.
What follows is a personal statement about why I think WinDbg is worth
improving.
WinDbg is free, and that, in my mind, is the cause of these types of
problems, because they don’t exist, in my experience, in other Microsoft
products. While this is very understandable, if it is in fact what is
going on, I think it is a mistake. A lot of talk goes on here about
what can be done to improve stability of production drivers. Some of
the solutions are, in my opinion, rather extreme, and, should they not
be your personal cup of tea, have somewhat of a vaguely facist feel to
them, as it were. I don’t mean that in a conspiracy/monopoly theory
sort of way, or other nonsense of that sort. I just mean, some of these
things that are really being pushed hard, at the moment, have very
obvious problems that aren’t exactly highlighted. Microsoft will fix
them; they always do. I have no doubt, that DTM, for example, will
someday provide legitimate value to some developers. Presently, the
situation doesn’t need any comment. I can’t say that I have any idea of
what the deal with Driver Signing is, because it seems like it should be
straightforward, but most definitely, at present, is not.
The most significant thing that I think gets more or less left out of
the information and advice is that almost all of these solutions, though
not without merit, at least initially present a huge learning curve that
involves changing the set of practices and pecedilos that make each of
us an individual, for better or worse. WPP, in my mind, is the a good
example of this. Apparently, it can do your taxes for you in a virtual,
visual, object oriented, internet aware way that meets the needs of
developers of robust, mission-critical software with a short time to
market; that is, if you are willing to change your build procedures and
the way printf statements have been terminated since the dawn of time,
possibly among other things. Frankly, I don’t know what else, may be
nothing, because I know nothing else about WPP, because I stopped
looking as soon as heard about ‘\n’ thing, also for better or worse. In
my opinion, that’s a pretty common response, even among good,
responsible developers.
So, here’s where I’m going with all of this. In my opinion, improving
WinDbg would be the single best thing that could be done toward the goal
of improving system stability. Basically, this would start with a
complete rewrite of the documentation that featured documentation of all
the extensions (whoever may or may not have written them); an index
created by a human being with enough knowledge of the subject to provide
alternatives to either the ‘0’ or ‘500’ hits that most searches seem to
produce; a set of tables or other documents that grouped extensions by
category (i. e. - these are the extensions for virtual memory
management), taking in to account the (formidable) problem of most
commands being two or three letters long. Improvements to the UI would
be nice, and there some extensions that desperately need to get fixed
(!vtop and !ptov come to mind), but realization of the wishes expressed
in the previous sentence would make me positively giddy. Should any of
this materialize, it will not by a long shot produce obviously
significant improvements in stability, but nothing that doesn’t restrict
who can develop drivers is going to do produce results of that
magnitude.
While it certainly is true that, at best, we are a tiny group of
developers, and one with wants that are largely orthogonal to those of
the incomparably larger user mode community, another valid way of
looking at it is that, according to Microsoft, out of however many
bluescreens that have occurred in the time it has taken me to write
this, we are largely responsible for the vast majority of them. I agree
100% with the Microsoft figures.
I may be completely incorrect about allocating some additional
resources to WinDbg being beneficial, but it seems to me that
reassigning a truly small handful of people from solutions that have the
same goal - say Driver Signing, DTM and WPP - is an experiment well
worth running.
mm
>>> xxxxx@acm.org 2007-05-08 14:24 >>>
Jason,
I’ve reported this on and off for over a year (I will not comment
on
the responses). THERE ARE NO EASY REPRO STEPS, OR I WOULD NOT DO THAT
ANY
MORE!!! I am using 3 WindDBG’s, a copy of Outlook Express,
VS6,
and the latest WDK documentation, I toggle between windows (including
minimizing things), and “poof” WinDBG looses its mind or at least its
GUI.
I refuse to use any docked Windows, since I find them worse than
worthless,
which may contribute to this. By the way all of the first three
happened
in a 90 minute debugging session this morning.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Jason Cunningham” wrote in message
news:xxxxx@windbg…
Please report bugs to xxxxx@microsoft.com. That’s the way to get
someone to look at them and consider a fix. I look forward to your
mail
with repro steps for #1-3. #4 I can repro, and IIRC it’s a problem
with
the control class we use, rather than a debugger bug. A fix there is
not
likely any time soon. If your steps don’t involve switching focus off
the
source window or not having focus there in the first place, please send
your steps for it as well since they’re different than mine.
Thanks,
Jason
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Saturday, May 05, 2007 5:36 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Old release of WinDbg
“Spiro Trikaliotis” wrote in message
news:xxxxx@windbg…
> The new UI is something for itself. I did not like it very much in
the
> first place. Now, I’ve got used to it. In fact, I do not remember
the
> older interface, so, I am not sure how I would rate it now.
> Nevertheless, the new UI is somehow problematic if I want to arrange
my
> Windows as I like them. I often have to try more than once before it
> works as I want to. I did not have any real problems with the UI for
> some versions of WinDBG, however.
>
My biggest problem with the new WinDBG is the UI. My four favorites
are:
1. I have the “disappearing window” syndrome at least twice a day,
this
is where WinDBG disappears from the task bar, and if you are like me
and
have a lot of applications up, trying to find WinDBG is a royal pain.
2. Another variant of this is the disappearing main window, I.E. the
window with the menus etc disappears off the desktop, this one keeps it
on
the taskbar so the solution is to maximize the window which redisplays
it,
then shrink it down so it is the size you want.
3. On the opposite end of the scale you get the command window as a
seperate taskbar item. So there are to task bar entries, considering I
am
debugging a distruted file system at the moment and have 3 WinDBG’s up
all
the time, having 6 items on the task bar is a pain.
4. Finally, the “flying scroll” on the source windows. I break in to
set
a breakpoint, and scroll to the place where I want it, around 30% of
the
time something happens such as when I go to select the line, the
window
scrolls extremely quickly back to the place it was prior to my
scrolling.
Now considering these are big files, this is very unfriendly. This
one
could be me, but I haven’t figured out the magic to stop it.
Overall, my biggest complaint with the new UI, is that it gets in the
way
(the four items above are some of the biggies). For a debugger getting
in
the way or making you think about the debugger rather than the bug is
the
cardinal sin. I have managed teams where I wrote and owned debugger’s
and
I would never have accepted something like this.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply