Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
Upcoming OSR Seminars | ||
---|---|---|
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
Kernel Debugging | 13-17 May 2024 | Live, Online |
Developing Minifilters | 1-5 Apr 2024 | Live, Online |
Internals & Software Drivers | 11-15 Mar 2024 | Live, Online |
Writing WDF Drivers | 26 Feb - 1 Mar 2024 | Live, Online |
Comments
and neither 2127 or the Sep 99 versions I'm using are worth using as
toilette paper, I'm really hoping this will work. <crossing all fingers>.
We shall see what we shall see ....
-----Original Message-----
From: Nathan Nesbit [mailto:[email protected]]
Sent: Tuesday, June 13, 2000 8:49 AM
To: NT Developers Interest List
Subject: [ntdev] New test release of WinDBG
-----Original Message-----
From: Andre Vachon
My team has just released a new test version of WinDBG on
http://www.microsoft.com/ddk/debugging
<http://www.microsoft.com/ddk/debugging>
We have done some major work on the UI, reenabling all the important
features that were missing from the WinHEC release.
We have added a number of new debugger commands, and fixed a lot of bugs
reported by our internal users.
We are acutally getting more internal usage of WinDBG then ever. Many of
the hardcore i386kd.exe users are now using WinDBG, and we have had very few
complaints (all of which have been fixed already)
So I really hope you will give it a try and give us some feedback at
[email protected]
We appreciate the good feeback but really want to hear about the bad. Don't
get frustrated with the debugger - let us know about the problems so we can
fix them !
I also encourage *everyone* to take a look through the documentation.
I especially encourage advanced users to look through the reference section
for the debugger commands, as we have enhanced and added many commands. A
number of commands have also changed from the old WinDBG as our command
syntax is based on i386kd.exe
If you find any bugs (even bugsin the documentation), please let us know -
we will do our best to get them fixed quickly.
Bugs, request for features, praise, complaints, etc : send mail to
[email protected]
Thanks,
The WinDBG team.
---
You are currently subscribed to windbg as: [email protected]
To unsubscribe send a blank email to [email protected]
GUI still needs work, as in it keeps re-arranging my windows :-( ;
Crash dump analysis and live debugging appear to be much more stabile
than either the prior release or the existing old version windbags. 3
Smileys!
Bottom line: worth looking into if you are a current windbag user.
Warning: not tested on NT4 target or host as I upgraded my last NT4 system.
Nathan: hang in there fella, the thumb is horizontal!
-----Original Message-----
From: Nathan Nesbit [mailto:[email protected]]
Sent: Tuesday, June 13, 2000 11:49 AM
To: NT Developers Interest List
Subject: [ntdev] New test release of WinDBG
-----Original Message-----
From: Andre Vachon
My team has just released a new test version of WinDBG on
http://www.microsoft.com/ddk/debugging
We have done some major work on the UI, reenabling all the important
features that were missing from the WinHEC release.
We have added a number of new debugger commands, and fixed a lot of bugs
reported by our internal users.
We are acutally getting more internal usage of WinDBG then ever. Many of
the hardcore i386kd.exe users are now using WinDBG, and we have had very few
complaints (all of which have been fixed already)
So I really hope you will give it a try and give us some feedback at
[email protected]
We appreciate the good feeback but really want to hear about the bad. Don't
get frustrated with the debugger - let us know about the problems so we can
fix them !
I also encourage *everyone* to take a look through the documentation.
I especially encourage advanced users to look through the reference section
for the debugger commands, as we have enhanced and added many commands. A
number of commands have also changed from the old WinDBG as our command
syntax is based on i386kd.exe
If you find any bugs (even bugsin the documentation), please let us know -
we will do our best to get them fixed quickly.
Bugs, request for features, praise, complaints, etc : send mail to
[email protected]
Thanks,
The WinDBG team.
---
You are currently subscribed to windbg as: [email protected]
To unsubscribe send a blank email to [email protected]
-----Original Message-----
From: Roddy, Mark [mailto:[email protected]]
Sent: Tuesday, June 13, 2000 9:07 AM
To: NT Developers Interest List
Subject: [ntdev] RE: New test release of WinDBG
First impressions:
GUI still needs work, as in it keeps re-arranging my windows :-( ;
Crash dump analysis and live debugging appear to be much more
stabile than either the prior release or the existing old version
windbags. 3 Smileys!
Bottom line: worth looking into if you are a current windbag user.
Warning: not tested on NT4 target or host as I upgraded my last NT4
system.
Nathan: hang in there fella, the thumb is horizontal!
-----Original Message-----
From: Nathan Nesbit [mailto:[email protected]]
Sent: Tuesday, June 13, 2000 11:49 AM
To: NT Developers Interest List
Subject: [ntdev] New test release of WinDBG
-----Original Message-----
From: Andre Vachon
My team has just released a new test version of WinDBG on
http://www.microsoft.com/ddk/debugging
We have done some major work on the UI, reenabling all the important
features that were missing from the WinHEC release.
We have added a number of new debugger commands, and fixed a lot of bugs
reported by our internal users.
We are acutally getting more internal usage of WinDBG then ever. Many
of the hardcore i386kd.exe users are now using WinDBG, and we have had
very few complaints (all of which have been fixed already)
So I really hope you will give it a try and give us some feedback at
[email protected]
We appreciate the good feeback but really want to hear about the bad.
Don't get frustrated with the debugger - let us know about the problems
so we can fix them !
I also encourage *everyone* to take a look through the documentation.
I especially encourage advanced users to look through the reference
section for the debugger commands, as we have enhanced and added many
commands. A number of commands have also changed from the old WinDBG as
our command syntax is based on i386kd.exe
If you find any bugs (even bugsin the documentation), please let us know
- we will do our best to get them fixed quickly.
Bugs, request for features, praise, complaints, etc : send mail to
[email protected]
Thanks,
The WinDBG team.
---
You are currently subscribed to windbg as: [email protected]
To unsubscribe send a blank email to [email protected]
that for Whistler only ?
Regards,
Paul Bunn, UltraBac.com, 425-644-6000
Microsoft MVP - WindowsNT/2000
http://www.ultrabac.com
-----Original Message-----
From: Nathan Nesbit [mailto:[email protected]]
Sent: Tuesday, June 13, 2000 8:49 AM
To: NT Developers Interest List
Subject: [ntdev] New test release of WinDBG
My team has just released a new test version of WinDBG on
http://www.microsoft.com/ddk/debugging
We have done some major work on the UI, reenabling all the important
features that were missing from the WinHEC release.
We have added a number of new debugger commands, and fixed a lot of bugs
reported by our internal users.
We are acutally getting more internal usage of WinDBG then ever. Many of
the hardcore i386kd.exe users are now using WinDBG, and we have had very few
complaints (all of which have been fixed already)
So I really hope you will give it a try and give us some feedback at
[email protected]
We appreciate the good feeback but really want to hear about the bad. Don't
get frustrated with the debugger - let us know about the problems so we can
fix them !
I also encourage *everyone* to take a look through the documentation.
I especially encourage advanced users to look through the reference section
for the debugger commands, as we have enhanced and added many commands. A
number of commands have also changed from the old WinDBG as our command
syntax is based on i386kd.exe
If you find any bugs (even bugsin the documentation), please let us know -
we will do our best to get them fixed quickly.
Bugs, request for features, praise, complaints, etc : send mail to
[email protected]
Thanks,
fixed currently, but I think it is valuable that this is going out to get
your feedback. I wanted to offer my own email address if you don't get a
response from submitting a windbg bug - or just want to hit a real person
with your issue.
Best bet to having a bug fixed is to make sure you supply OS and windbg
versions and the exact repro scenario. We can repro it here in Developer
Support, and submit the bug.
Bill Stuart
Microsoft, Program Manager, EE, IEEE, Windows Systems Developer Support
engineering support for core software and hardware developers
http://support.microsoft.com/support/
ddk - DDK support pages
http://www.microsoft.com/ ddk/ - download DDK's
http://www.microsoft.com/
support/customer/develop.htm - Support options
http://www.microsoft.com/ hwdev/ - general
hardware development
http://www.microsoft.com/ mswish/ - make a
product wish - choose DDK category
sort
-----Original Message-----
From: Nathan Nesbit [mailto:[email protected]]
Sent: Tuesday, June 13, 2000 8:49 AM
To: NT Developers Interest List
Subject: [ntdev] New test release of WinDBG
-----Original Message-----
From: Andre Vachon
My team has just released a new test version of WinDBG on
http://www.microsoft.com/ddk/debugging
We have done some major work on the UI, reenabling all the important
features that were missing from the WinHEC release.
We have added a number of new debugger commands, and fixed a lot of bugs
reported by our internal users.
We are acutally getting more internal usage of WinDBG then ever. Many of
the hardcore i386kd.exe users are now using WinDBG, and we have had very few
complaints (all of which have been fixed already)
So I really hope you will give it a try and give us some feedback at
[email protected]
We appreciate the good feeback but really want to hear about the bad. Don't
get frustrated with the debugger - let us know about the problems so we can
fix them !
I also encourage *everyone* to take a look through the documentation.
I especially encourage advanced users to look through the reference section
for the debugger commands, as we have enhanced and added many commands. A
number of commands have also changed from the old WinDBG as our command
syntax is based on i386kd.exe
If you find any bugs (even bugsin the documentation), please let us know -
we will do our best to get them fixed quickly.
Bugs, request for features, praise, complaints, etc : send mail to
[email protected]
Thanks,
The WinDBG team.
---
You are currently subscribed to windbg as: [email protected]
To unsubscribe send a blank email to [email protected]
Thank you. Big improvement. I've been using it for several hours and so far
NO crashes, and .reboot WORKS!!!! The only real problems I've had have been
related to procedure and command changes, and those have been resolved in
the documentation. I've detailed below some of the things I've found. If it
continues to function, I'll be removing the other pieces of crap I've been
using.
Oh, I'm using it to debug an NT device driver on a Dual Processor, using NT
4.0, SP4.
I like the way the Locals window is grayed out but retains the last valid
data for review. In fact there is several things I like.
Caveats:
Absolutely, read the manual. If you're in a hurry, looking
at "Installation and set up" is a must or your going to start slapping your
keyboard and cussing developers that like to change existing interfaces.
<blush>
Pain in the butt:
Tabs --- I finally figured out that if I multiply by 4 I could get
my code to line up properly.
Hopefully you will fix it such that 1 tab stop equals 1
character.
Ctrl-Break message
Give me a means of making it go away (I may have missed it
in the docs, however)
Local labels
Did not at first appear, at all, period!!! Went stomping
back through the documentation muttering nasty
comments, and finally figured out that I needed to generate
a pdb file. Wonderful, how do you do that!? So
now into the VC++ documentation and finally found that you
do that by setting the check boxes in the Linker
tab in the Settings dialog.
Why do all those "Save ???? workspace" queries pop up when
you do a .reboot? I'm rebooting the remote, not quitting WinDBG. It's a pain
because sometimes I need to empty my elderly bladder while the target system
reboots.
Wish list:
Oddly enough, I miss the C structuring colors ... I hope they are added back
before release.
Other color changes ...
Go back to Green for a breakpoint hit, yellow for stepping, and
magenta for a non instantiated break-point.
Gary
-----Original Message-----
From: Gary Little [mailto:[email protected]]
Sent: Tuesday, June 13, 2000 9:08 AM
To: NT Developers Interest List
Subject: [ntdev] RE: New test release of WinDBG
Just downloaded and installed it. Since I'm in a very heavy
debug session,
and neither 2127 or the Sep 99 versions I'm using are worth
using as
toilette paper, I'm really hoping this will work. .
We shall see what we shall see ....
-----Original Message-----
From: Nathan Nesbit [mailto:[email protected]]
Sent: Tuesday, June 13, 2000 8:49 AM
To: NT Developers Interest List
Subject: [ntdev] New test release of WinDBG
-----Original Message-----
From: Andre Vachon
My team has just released a new test version of WinDBG on
http://www.microsoft.com/ddk/debugging
<http://www.microsoft.com/ddk/debugging>
We have done some major work on the UI, reenabling all the
important
features that were missing from the WinHEC release.
We have added a number of new debugger commands, and fixed a
lot of bugs
reported by our internal users.
We are acutally getting more internal usage of WinDBG then
ever. Many of
the hardcore i386kd.exe users are now using WinDBG, and we
have had very few
complaints (all of which have been fixed already)
So I really hope you will give it a try and give us some
feedback at
[email protected]
We appreciate the good feeback but really want to hear about
the bad. Don't
get frustrated with the debugger - let us know about the
problems so we can
fix them !
I also encourage *everyone* to take a look through the
documentation.
I especially encourage advanced users to look through the
reference section
for the debugger commands, as we have enhanced and added
many commands. A
number of commands have also changed from the old WinDBG as
our command
syntax is based on i386kd.exe
If you find any bugs (even bugsin the documentation), please
let us know -
we will do our best to get them fixed quickly.
Bugs, request for features, praise, complaints, etc : send
mail to
[email protected]
Thanks,
The WinDBG team.
---
You are currently subscribed to windbg as:
[email protected]
To unsubscribe send a blank email to
[email protected]
---
You are currently subscribed to ntdev as:
[email protected]
To unsubscribe send a blank email to
$subst('Email.Unsub')
> Tabs --- I finally figured out that if I multiply by 4 I could
get
We will get this fixed.
> Ctrl-Break message
I assume you mean what appears when someone hits
ctrl-c/ctrl-break while kernel debugging.
You can turn that off by defining the env var KDQUIET
and set it equal to anything. Then start windbg with this defined & you
will not see the message. We will update the docs on this.
> Local labels
We will improve the docs on this point. Also remember
that optimized code does whatever it wants with your locals & the
debugger is not given enough information to make complete sense of it.
So source level debug unoptimized code if possible.
> Why do all those "Save ???? workspace" queries pop up when
If you hit "Yes" to one then you shouldn't get them near
as much. We know about this and are improving it.
> Oddly enough, I miss the C structuring colors ... I hope they are
added back
> Go back to Green for a breakpoint hit, yellow for stepping, and
We will look into this
-----Original Message-----
From: Gary Little [mailto:[email protected]]
Sent: Tuesday, June 13, 2000 12:16 PM
To: NT Developers Interest List
Subject: [ntdev] RE: New test release of WinDBG
Nathan,
Thank you. Big improvement. I've been using it for several hours and so
far
NO crashes, and .reboot WORKS!!!! The only real problems I've had have
been
related to procedure and command changes, and those have been resolved
in
the documentation. I've detailed below some of the things I've found. If
it
continues to function, I'll be removing the other pieces of crap I've
been
using.
Oh, I'm using it to debug an NT device driver on a Dual Processor, using
NT
4.0, SP4.
I like the way the Locals window is grayed out but retains the last
valid
data for review. In fact there is several things I like.
Caveats:
Absolutely, read the manual. If you're in a hurry,
looking
at "Installation and set up" is a must or your going to start slapping
your
keyboard and cussing developers that like to change existing interfaces.
Pain in the butt:
Tabs --- I finally figured out that if I multiply by 4 I could
get
my code to line up properly.
Hopefully you will fix it such that 1 tab stop equals 1
character.
Ctrl-Break message
Give me a means of making it go away (I may have missed
it
in the docs, however)
Local labels
Did not at first appear, at all, period!!! Went stomping
back through the documentation muttering nasty
comments, and finally figured out that I needed to
generate
a pdb file. Wonderful, how do you do that!? So
now into the VC++ documentation and finally found that
you
do that by setting the check boxes in the Linker
tab in the Settings dialog.
Why do all those "Save ???? workspace" queries pop up
when
you do a .reboot? I'm rebooting the remote, not quitting WinDBG. It's a
pain
because sometimes I need to empty my elderly bladder while the target
system
reboots.
Wish list:
Oddly enough, I miss the C structuring colors ... I hope they are added
back
before release.
Other color changes ...
Go back to Green for a breakpoint hit, yellow for stepping, and
magenta for a non instantiated break-point.
Gary
-----Original Message-----
From: Gary Little [mailto:[email protected]]
Sent: Tuesday, June 13, 2000 9:08 AM
To: NT Developers Interest List
Subject: [ntdev] RE: New test release of WinDBG
Just downloaded and installed it. Since I'm in a very
heavy
debug session,
and neither 2127 or the Sep 99 versions I'm using are
worth
using as
toilette paper, I'm really hoping this will work.
.
We shall see what we shall see ....
-----Original Message-----
From: Nathan Nesbit
[mailto:[email protected]]
Sent: Tuesday, June 13, 2000 8:49 AM
To: NT Developers Interest List
Subject: [ntdev] New test release of WinDBG
-----Original Message-----
From: Andre Vachon
My team has just released a new test version of WinDBG
on
http://www.microsoft.com/ddk/debugging
We have done some major work on the UI, reenabling all
the
important
features that were missing from the WinHEC release.
We have added a number of new debugger commands, and
fixed a
lot of bugs
reported by our internal users.
We are acutally getting more internal usage of WinDBG
then
ever. Many of
the hardcore i386kd.exe users are now using WinDBG, and
we
have had very few
complaints (all of which have been fixed already)
So I really hope you will give it a try and give us some
feedback at
[email protected]
We appreciate the good feeback but really want to hear
about
the bad. Don't
get frustrated with the debugger - let us know about the
problems so we can
fix them !
I also encourage *everyone* to take a look through the
documentation.
I especially encourage advanced users to look through
the
reference section
for the debugger commands, as we have enhanced and added
many commands. A
number of commands have also changed from the old WinDBG
as
our command
syntax is based on i386kd.exe
If you find any bugs (even bugsin the documentation),
please
let us know -
we will do our best to get them fixed quickly.
Bugs, request for features, praise, complaints, etc :
send
mail to
[email protected]
Thanks,
The WinDBG team.
---
You are currently subscribed to windbg as:
[email protected]
To unsubscribe send a blank email to
[email protected]
---
You are currently subscribed to ntdev as:
[email protected]
To unsubscribe send a blank email to
$subst('Email.Unsub')
---
You are currently subscribed to ntdev as: [email protected]
To unsubscribe send a blank email to $subst('Email.Unsub')
Thank you. This release is a big improvement as far as reliability goes. I
do have a few comments, suggestions, and a couple of complaints, but overall
after 10 hours of use it's looking good.
The Number 1 complaint: I (and all my co-workers) do not think that ENTER
should be = Command Repeat by default. If there is a way to turn this off
and make it NOT the default then we have no problem with this. We have lost
multiple debug sessions today by hitting enter accidentally and getting a GO
command.
Like:
1. Ability to customize "Calls" window.
2. "Locals" window maintaining values after continuing.
3. Uses the color scheme on the Host system(big kudos for that one!)
4.
Don't Like:
1. *** ENTER key is Repeat command by default(mentioned above)
2. You can no longer do a >help <command> to get more explanation of a
command.
3. All those "Save Workspace?" queries. You lose the ability to reboot and
walk away for a moment.
4. If you Maximize the "Command" window you still have the Command window's
title bar at the top. This doesn't occur for the other windows like "Calls"
and "Locals".
Mixed Bag:
1. We like being able to type the commands in a separate pane of the Command
windows but dislike even more not being able to use movement keys like "Page
Up" and "Page Down" to navigate through the command window output without
first changing the focus to that pane. I'm not sure how you fix that, but at
this point is more inconvenient than convenient.
Suggestions:
1. Customization of certain color items like current line, breakpoint hit,
etc.
2. Add a command that will dump to the command window:(kinda' like .setopt)
a. Each workspace type and each of their current values contained within
b. Any non-workspace options currently set
Keep up the GREAT Work! It is really appreciated.
michael miles
-----Original Message-----
From: Nathan Nesbit [mailto:[email protected]]
Sent: Tuesday, June 13, 2000 11:49 AM
To: NT Developers Interest List
Subject: [ntdev] New test release of WinDBG
-----Original Message-----
From: Andre Vachon
My team has just released a new test version of WinDBG on
http://www.microsoft.com/ddk/debugging
We have done some major work on the UI, reenabling all the important
features that were missing from the WinHEC release.
We have added a number of new debugger commands, and fixed a lot of bugs
reported by our internal users.
We are acutally getting more internal usage of WinDBG then ever. Many of
the hardcore i386kd.exe users are now using WinDBG, and we have had very few
complaints (all of which have been fixed already)
So I really hope you will give it a try and give us some feedback at
[email protected]
We appreciate the good feeback but really want to hear about the bad. Don't
get frustrated with the debugger - let us know about the problems so we can
fix them !
I also encourage *everyone* to take a look through the documentation.
I especially encourage advanced users to look through the reference section
for the debugger commands, as we have enhanced and added many commands. A
number of commands have also changed from the old WinDBG as our command
syntax is based on i386kd.exe
If you find any bugs (even bugsin the documentation), please let us know -
we will do our best to get them fixed quickly.
Bugs, request for features, praise, complaints, etc : send mail to
[email protected]
Thanks,
The WinDBG team.
---
You are currently subscribed to windbg as: [email protected]
To unsubscribe send a blank email to [email protected]
to address everyone's needs.
>1. *** ENTER key is Repeat command by default(mentioned above)
We'll look into it
>2. You can no longer do a >help
This has changed. If you do a .help you get some commands /w a
short description. If you do a .hh
come up with the index set to the command. The HTLM help is much better
than anything we could provide in the command window.
>3. All those "Save Workspace?" queries. You lose the ability to reboot
and
We are working on this. For now save the workspace & you will
not get near as many prompts.
>4. If you Maximize the "Command" window you still have the Command
window's
I can't get anything like this to happen. Can you send me the
following info:
OS Windbg is running on
OS you are trying to debug
Exact steps to repro
>1. We like being able to type the commands in a separate pane of the
Command
>windows but dislike even more not being able to use movement keys like
"Page
>Up" and "Page Down" to navigate through the command window output
without
We'll look into it
>1. Customization of certain color items like current line, breakpoint
hit,
We will look into this
>2. Add a command that will dump to the command window:(kinda' like
.setopt)
a. Each workspace type and each of their current values
contained within
b. Any non-workspace options currently set
So this would be a "dump settings" command? We will look into
this.
-----Original Message-----
From: Miles, Michael S [mailto:[email protected]]
Sent: Tuesday, June 13, 2000 2:59 PM
To: NT Developers Interest List
Cc: Nathan Nesbit
Subject: [ntdev] RE: New test release of WinDBG
Nathan,
Thank you. This release is a big improvement as far as reliability goes.
I
do have a few comments, suggestions, and a couple of complaints, but
overall
after 10 hours of use it's looking good.
The Number 1 complaint: I (and all my co-workers) do not think that
ENTER
should be = Command Repeat by default. If there is a way to turn this
off
and make it NOT the default then we have no problem with this. We have
lost
multiple debug sessions today by hitting enter accidentally and getting
a GO
command.
Like:
1. Ability to customize "Calls" window.
2. "Locals" window maintaining values after continuing.
3. Uses the color scheme on the Host system(big kudos for that one!)
4.
Don't Like:
1. *** ENTER key is Repeat command by default(mentioned above)
2. You can no longer do a >help
command.
3. All those "Save Workspace?" queries. You lose the ability to reboot
and
walk away for a moment.
4. If you Maximize the "Command" window you still have the Command
window's
title bar at the top. This doesn't occur for the other windows like
"Calls"
and "Locals".
Mixed Bag:
1. We like being able to type the commands in a separate pane of the
Command
windows but dislike even more not being able to use movement keys like
"Page
Up" and "Page Down" to navigate through the command window output
without
first changing the focus to that pane. I'm not sure how you fix that,
but at
this point is more inconvenient than convenient.
Suggestions:
1. Customization of certain color items like current line, breakpoint
hit,
etc.
2. Add a command that will dump to the command window:(kinda' like
.setopt)
a. Each workspace type and each of their current values contained within
b. Any non-workspace options currently set
Keep up the GREAT Work! It is really appreciated.
michael miles
-----Original Message-----
From: Nathan Nesbit [mailto:[email protected]]
Sent: Tuesday, June 13, 2000 11:49 AM
To: NT Developers Interest List
Subject: [ntdev] New test release of WinDBG
-----Original Message-----
From: Andre Vachon
My team has just released a new test version of WinDBG on
http://www.microsoft.com/ddk/debugging
We have done some major work on the UI, reenabling all the important
features that were missing from the WinHEC release.
We have added a number of new debugger commands, and fixed a lot of bugs
reported by our internal users.
We are acutally getting more internal usage of WinDBG then ever. Many
of
the hardcore i386kd.exe users are now using WinDBG, and we have had very
few
complaints (all of which have been fixed already)
So I really hope you will give it a try and give us some feedback at
[email protected]
We appreciate the good feeback but really want to hear about the bad.
Don't
get frustrated with the debugger - let us know about the problems so we
can
fix them !
I also encourage *everyone* to take a look through the documentation.
I especially encourage advanced users to look through the reference
section
for the debugger commands, as we have enhanced and added many commands.
A
number of commands have also changed from the old WinDBG as our command
syntax is based on i386kd.exe
If you find any bugs (even bugsin the documentation), please let us know
-
we will do our best to get them fixed quickly.
Bugs, request for features, praise, complaints, etc : send mail to
[email protected]
Thanks,
The WinDBG team.
---
You are currently subscribed to windbg as: [email protected]
To unsubscribe send a blank email to [email protected]
---
You are currently subscribed to ntdev as: [email protected]
To unsubscribe send a blank email to $subst('Email.Unsub')
(trying to forgo the NT4 windbg) trying to see symbols in
my driver via ?<driver>!<symbol>. I get back nonsense values.
x <driver>!<symbol> produces same (nonsense) value. 'lm'
shows that the symbols have been loaded (sympath is correct).
What's the secret setting to see my symbols correctly?
Pete
release of 'Bag2 looks pretty darn good.
Gripes: in addition to those already listed, I tend to run long sessions and
I like to punctuate the log with a lot of white space separating events of
interest. The modal nature of the command entry window prevents one from
doing this while the target system is running, the command repeat setting of
ENTER makes this problematic when the system is stopped.
Has anybody tried the remote features?
-----Original Message-----
From: Nathan Nesbit [mailto:[email protected]]
Sent: Tuesday, June 13, 2000 6:19 PM
To: NT Developers Interest List
Subject: [ntdev] RE: New test release of WinDBG
I'm glad you all like it. The whole debugger team has been working hard to
address everyone's needs.
>1. *** ENTER key is Repeat command by default(mentioned above)
We'll look into it
>2. You can no longer do a >help
This has changed. If you do a .help you get some commands /w a
short description. If you do a .hh
with the index set to the command. The HTLM help is much better than
anything we could provide in the command window.
>3. All those "Save Workspace?" queries. You lose the ability to reboot and
We are working on this. For now save the workspace & you will not
get near as many prompts.
>4. If you Maximize the "Command" window you still have the Command window's
I can't get anything like this to happen. Can you send me the
following info:
OS Windbg is running on
OS you are trying to debug
Exact steps to repro
>1. We like being able to type the commands in a separate pane of the
Command
>windows but dislike even more not being able to use movement keys like
"Page
>Up" and "Page Down" to navigate through the command window output without
We'll look into it
>1. Customization of certain color items like current line, breakpoint hit,
We will look into this
>2. Add a command that will dump to the command window:(kinda' like .setopt)
a. Each workspace type and each of their current values contained
within
b. Any non-workspace options currently set
So this would be a "dump settings" command? We will look into this.
-----Original Message-----
From: Miles, Michael S [ mailto:[email protected]
]
Sent: Tuesday, June 13, 2000 2:59 PM
To: NT Developers Interest List
Cc: Nathan Nesbit
Subject: [ntdev] RE: New test release of WinDBG
Nathan,
Thank you. This release is a big improvement as far as reliability goes. I
do have a few comments, suggestions, and a couple of complaints, but overall
after 10 hours of use it's looking good.
The Number 1 complaint: I (and all my co-workers) do not think that ENTER
should be = Command Repeat by default. If there is a way to turn this off
and make it NOT the default then we have no problem with this. We have lost
multiple debug sessions today by hitting enter accidentally and getting a GO
command.
Like:
1. Ability to customize "Calls" window.
2. "Locals" window maintaining values after continuing.
3. Uses the color scheme on the Host system(big kudos for that one!)
4.
Don't Like:
1. *** ENTER key is Repeat command by default(mentioned above)
2. You can no longer do a >help
command.
3. All those "Save Workspace?" queries. You lose the ability to reboot and
walk away for a moment.
4. If you Maximize the "Command" window you still have the Command window's
title bar at the top. This doesn't occur for the other windows like "Calls"
and "Locals".
Mixed Bag:
1. We like being able to type the commands in a separate pane of the Command
windows but dislike even more not being able to use movement keys like "Page
Up" and "Page Down" to navigate through the command window output without
first changing the focus to that pane. I'm not sure how you fix that, but at
this point is more inconvenient than convenient.
Suggestions:
1. Customization of certain color items like current line, breakpoint hit,
etc.
2. Add a command that will dump to the command window:(kinda' like .setopt)
a. Each workspace type and each of their current values contained within
b. Any non-workspace options currently set
Keep up the GREAT Work! It is really appreciated.
michael miles
-----Original Message-----
From: Nathan Nesbit [ mailto:[email protected]
]
Sent: Tuesday, June 13, 2000 11:49 AM
To: NT Developers Interest List
Subject: [ntdev] New test release of WinDBG
-----Original Message-----
From: Andre Vachon
My team has just released a new test version of WinDBG on
http://www.microsoft.com/ddk/debugging
We have done some major work on the UI, reenabling all the important
features that were missing from the WinHEC release.
We have added a number of new debugger commands, and fixed a lot of bugs
reported by our internal users.
We are acutally getting more internal usage of WinDBG then ever. Many of
the hardcore i386kd.exe users are now using WinDBG, and we have had very few
complaints (all of which have been fixed already)
So I really hope you will give it a try and give us some feedback at
[email protected]
We appreciate the good feeback but really want to hear about the bad. Don't
get frustrated with the debugger - let us know about the problems so we can
fix them !
I also encourage *everyone* to take a look through the documentation.
I especially encourage advanced users to look through the reference section
for the debugger commands, as we have enhanced and added many commands. A
number of commands have also changed from the old WinDBG as our command
syntax is based on i386kd.exe
If you find any bugs (even bugsin the documentation), please let us know -
we will do our best to get them fixed quickly.
Bugs, request for features, praise, complaints, etc : send mail to
[email protected]
Thanks,
The WinDBG team.
---
You are currently subscribed to windbg as: [email protected]
To unsubscribe send a blank email to [email protected]
---
You are currently subscribed to ntdev as: [email protected]
To unsubscribe send a blank email to $subst('Email.Unsub')
Normally in bugcheck, the target reports serial line activity by displaying
DTR/DSR, DCD, RTS/CTS, and SND/RCV. Normally when data is being exchanged
between host and target you will see SND/RCV going nuts. Overall that's
great. However, there is one 3 letter group that invokes a hell of a lot 4
letter comments --- MDM. I ain't got no modem in $&$*ing the line, its a
null modem cable. When MDM is seen it's reboot time. Period. Can this be
fixed, or at least "well patched"?
Gary