We run tests against both the internal full symbols and the external
public symbols. I don’t know exact numbers for each but I’m fairly sure
we do more testing against internal symbols than external symbols. This
is unlikely to change for several reasons:
-
Internal customers are as important for us as external customers.
-
It’s much simpler to create tests against internal resources. We
have a very small team – two testers for everything in the Debugging
Tools for Windows package – so we have to economize when possible.
-
The things that are most affected by public vs. private symbols are
extensions from the various teams around Microsoft. The debugger team
itself has a limited ability to create tests for arbitrary extensions
that we do not develop, thus our test team does not have primary
responsibility here.
We don’t do any testing from outside the corpnet; I don’t know of any
practical way to achieve that.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Tuesday, October 03, 2006 4:50 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Windbg 6.6.0007.5 hangs, screen redraw,
messages…
Drew,
I’m curious, how much of your testing is done against the public symbol
server, preferably from outside the MS corpnet? One of the things I’ve
observed over the years is that it seems there are a certain class of
problems that crop up “outside” because much of the testing is done
“inside” and thus assumes a scenario that proves to be untrue for your
external customers (and there are many of us…)
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Monday, October 02, 2006 4:09 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Windbg 6.6.0007.5 hangs, screen redraw,
messages…
We’ll investigate.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Monday, October 02, 2006 2:56 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Windbg 6.6.0007.5 hangs, screen redraw,
messages…
The garbled message is interesting since that’s being produced on the
target side and sent via DbgPrint. It’s hard to say if the garbling is
occurring on the target or if it’s a debugger bug on the host. If you
have a sequence of operations which repros it we can try and see if it
happens to us here.
I’ve seen the same garbled message ever since upgrading to 6.6.7.5.
Definitely the debugger side. Sequence to repro is enable driver
verifier on a driver and reboot.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Monday, October 02, 2006 2:11 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Windbg 6.6.0007.5 hangs, screen redraw,
messages…
When you’re seeing slowness, here are some things to check:
- Avoid extra symbol resolution - make sure all of your breakpoints and
watch window entries are valid. 2. Try setting your symbol path to a
local, empty directory just to see if it’s something to do with symbol
lookup times. 3. When you’re using serial kd try Ctrl+Alt+d in windbg to
turn on extra debug spew. If you see RESEND or other errors your serial
connection is not working reliably. Make sure that Legacy USB is
disabled in the target’s BIOS settings.
For the docked window issue that certainly sounds like a windbg bug. If
you can give us a repro we can investigate.
The garbled message is interesting since that’s being produced on the
target side and sent via DbgPrint. It’s hard to say if the garbling is
occurring on the target or if it’s a debugger bug on the host. If you
have a sequence of operations which repros it we can try and see if it
happens to us here.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Rod Widdowson
Sent: Friday, September 29, 2006 2:21 PM
To: Kernel Debugging Interest List
Subject: [windbg] Windbg 6.6.0007.5 hangs, screen redraw, messages…
I’m kinda tentative about putting this in because noone else has
commented on what appears to be a pretty major slow down in the most
recent windbg, but I’ve chatted to a couple of other people who are
seeing similar issues and so and it may not just be me.
I recently had to replace my work machine and as a result had to install
windbg 6.6.0007.5, it appears to me that this is a bit of a step back
from what I was previously running (version unknown but easily 16 months
old).
My major problem are huge delays, often just when single stepping, but
it is unpredictable when there will be a monster delay and when it will
just work.
I initially throught that it was consulting the symbol server (because
it seemed to get slightly better when I had no network), but doing a
!sym noisy didn’t show anything untoward. I have not looked to see the
messages that are pasing between host+target because I cannot remember
the incantation…
This is connecting via 1394 and serial (both COM & pipe), to x86 targets
(smp+non smp) running w2k, wxp & wnet.
Other things I have noticed, unrelated to the above and less
aggravating, but hardly calculated to endear this release to me.
- occassionally docked windows get confused as to their respective size
and overlap each other or the edge of the frame
- messages becoming garbled, particularly the one from verifier:
************************************************************************
*******
*
* This is the string you add to your checkin description
* Driver Verifier: Enabled for Wcall>
I don’t believe that it’s relevant (except perhaps for the last point),
but the only hosts (the machine running windbg.exe) I’ve run this on are
SMP and previously I only ever ran on on non SMP hosts.
I should add that the release isn’t so unusable that I’ve had to back
out to a previous version, but it sure is frustrating…
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com