FW: RE: Target machine hangs without breaking into debugger

If I respond to mails on windbg list I am receiving this mail every time. Can we inform this user not use this email id.

-Srin.

-----Original Message-----
From: AntiSpam UOL [mailto:xxxxx@uol.com.br]
Sent: Friday, July 25, 2003 10:13 AM
To: Kumar, Srin
Subject: RE:[windbg] RE: Target machine hangs without breaking into debugger

http:

http:

http:

Ol?,

Voc? enviou uma mensagem para xxxxx@uol.com.br
Para que sua mensagem seja encaminhada, por favor, http: clique aqui

Esta confirma??o ? necess?ria porque xxxxx@uol.com.br usa o Antispam UOL, um programa que elimina mensagens enviadas por rob?s, como pornografia, propaganda e correntes.

As pr?ximas mensagens enviadas para xxxxx@uol.com.br n?o precisar?o ser confirmadas*.
Caso voc? receba outro pedido de confirma??o, por favor, pe?a para xxxxx@uol.com.br inclu?-lo em sua lista de autorizados.

Aten??o! Se voc? n?o conseguir clicar no atalho acima, acesse este endere?o:
http://tira-teima.as.uol.com.br/challengeSender.html?data=3Fa5i%2Fz4YREHcsbil%2F65Nlf3gyoxiEc7oOD5ZZJAft4CYQ%2BnqfHgZDrFnKA6VTyELgWGbqCffKlB mDEfvXiCsl1ZDW%2F8afHQKMhxHvtC6wh7Oq35lHELH5bIoaUYngn7SwMqcB7gIlRizaGoSv1HmAIu hB0bhmMsMY7z2RoDZwYm0kcjlHHME7pZ3LxpSoor

_____

Hi,

You?ve just sent a message to xxxxx@uol.com.br
In order to confirm the sent message, please http: click here

This confirmation is necessary because xxxxx@uol.com.br uses Antispam UOL, a service that avoids unwanted messages like advertising, pornography, viruses, and spams.

Other messages sent to xxxxx@uol.com.br won’t need to be confirmed
.
*If you receive another confirmation request, please ask xxxxx@uol.com.br to include you in his/her authorized e-mail list.

Warning! If the link doesn?t work, please copy the address below and paste it on your browser:
http://tira-teima.as.uol.com.br/challengeSender.html?data=3Fa5i%2Fz4YREHcsbil%2F65Nlf3gyoxiEc7oOD5ZZJAft4CYQ%2BnqfHgZDrFnKA6VTyELgWGbqCffKlB mDEfvXiCsl1ZDW%2F8afHQKMhxHvtC6wh7Oq35lHELH5bIoaUYngn7SwMqcB7gIlRizaGoSv1HmAIu hB0bhmMsMY7z2RoDZwYm0kcjlHHME7pZ3LxpSoor

Use o http: AntiSpam UOL e proteja sua caixa postal</http:></http:></http:></http:></http:></http:>

Arrgh, these things are so annoying. The user will be sufficiently warned.

Thanks,

-scott


Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
wrote in message news:xxxxx@windbg…
If I respond to mails on windbg list I am receiving this mail every time. Can we inform this user not use this email id.

-Srin.

-----Original Message-----
From: AntiSpam UOL [mailto:xxxxx@uol.com.br]
Sent: Friday, July 25, 2003 10:13 AM
To: Kumar, Srin
Subject: RE:[windbg] RE: Target machine hangs without breaking into debugger

Ol?,

Voc? enviou uma mensagem para xxxxx@uol.com.br
Para que sua mensagem seja encaminhada, por favor, clique aqui

Esta confirma??o ? necess?ria porque xxxxx@uol.com.br usa o Antispam UOL, um programa que elimina mensagens enviadas por rob?s, como pornografia, propaganda e correntes.

As pr?ximas mensagens enviadas para xxxxx@uol.com.br n?o precisar?o ser confirmadas*.
Caso voc? receba outro pedido de confirma??o, por favor, pe?a para xxxxx@uol.com.br inclu?-lo em sua lista de autorizados.

Aten??o! Se voc? n?o conseguir clicar no atalho acima, acesse este endere?o:
http://tira-teima.as.uol.com.br/challengeSender.html?data=3Fa5i%2Fz4YREHcsbil%2F65Nlf3gyoxiEc7oOD5ZZJAft4CYQ%2BnqfHgZDrFnKA6VTyELgWGbqCffKlB mDEfvXiCsl1ZDW%2F8afHQKMhxHvtC6wh7Oq35lHELH5bIoaUYngn7SwMqcB7gIlRizaGoSv1HmAIu hB0bhmMsMY7z2RoDZwYm0kcjlHHME7pZ3LxpSoor

------------------------------------------------------------------------

Hi,

You?ve just sent a message to xxxxx@uol.com.br
In order to confirm the sent message, please click here

This confirmation is necessary because xxxxx@uol.com.br uses Antispam UOL, a service that avoids unwanted messages like advertising, pornography, viruses, and spams.

Other messages sent to xxxxx@uol.com.br won’t need to be confirmed
.
*If you receive another confirmation request, please ask xxxxx@uol.com.br to include you in his/her authorized e-mail list.

Warning! If the link doesn?t work, please copy the address below and paste it on your browser:
http://tira-teima.as.uol.com.br/challengeSender.html?data=3Fa5i%2Fz4YREHcsbil%2F65Nlf3gyoxiEc7oOD5ZZJAft4CYQ%2BnqfHgZDrFnKA6VTyELgWGbqCffKlB mDEfvXiCsl1ZDW%2F8afHQKMhxHvtC6wh7Oq35lHELH5bIoaUYngn7SwMqcB7gIlRizaGoSv1HmAIu hB0bhmMsMY7z2RoDZwYm0kcjlHHME7pZ3LxpSoor

Use o AntiSpam UOL e proteja sua caixa postal

I see I forgot to ask you what version of Windbg you are running? Please
look here:
http://www.microsoft.com/whdc/ddk/debugging/default.mspx
for the latest version of the debugger, if you don’t already know that you
have the latest one, which is less than two weeks old at this writing, and
is version 6.2.13.1.

Phil

Philip D. Barila Windows DDK MVP
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

“Leahy, Barbara C” <barbara.leahy> wrote in message
news:xxxxx@windbg…

Please expand more on the suggestion of using a slower baud rate on the
serial line. I want to know more about machine characteristics. I
heartly welcome more knowledge since I’m experiencing hangs on two
different machine models. I’ll share what I’ve learned so far in hopes
it will help.

I’ve found different results depending on the machine model of
the target. I use the same the machine, a 2GHZ, as the debugger
machine. The debugee/target machine is either a 450 MHZ or a 1GHZ. On
my old faithful target (450 MHZ Dual proc), for hangs using Windbg , I
send a kernel debug break again from the drop down list using the GUI
interface, not windbg command line entry. This causes a response. If I
don’t do this and just try issuing more commands from the windbg command
line, the machine does not respond. It is hung. This technique works
pretty well in most cases. On my troublesome newer machine (1GHZ), I
see a different behavior. The machine gets stuck/hung, and I’m not sure
how to fix it. I’ll try the suggestions of different serial line
speeds. Both machines are running same OS, same set of drivers.

So, if you are seeing your machine hung in the debugger, you may
want to see if that same behavior happens on another machine of
different characteristics. That gives you another piece of information
in the problem solving.

Barb</barbara.leahy>

Yes, let me clarify my request.

What I’d like info on is why would a slower baud rate work
better than a faster one or would it. I know both machines must match
the baud rate and how to set the baud rate up. When I read the email
about baud rates, I got the impression that a slower baud rate may
worker better on some machines. Is this true? What I wanted to know is
if some machines will work at higher baud rates, but handle slower baud
rates better. Is there an ideal baud rate that works best with certain
machines? I want to know what the test guys have found works best.
Guess I’ll have to experiment on my own.

From my experience after updating my debugger today, what version of the
debugger I’m using makes a difference. I better keep the versions around
that I like.

Thanks, Barb

-----Original Message-----
From: xxxxx@NAI.com [mailto:xxxxx@NAI.com]
Sent: Friday, July 25, 2003 10:09 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Target machine hangs without breaking into
debugger

On host, you set the serial line baudrate. When you selected Kernel
Debug from File menu in Com tab.

On target, you set the baudrate in your boot.ini using /baudrate=xxxx

The baudrate specified at the host and target should be the same. Look
windbg documentation for valid baudrate values…

-Srin.

-----Original Message-----
From: Leahy, Barbara C [mailto:barbara.leahy@hp.com]
Sent: Friday, July 25, 2003 7:50 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Target machine hangs without breaking into
debugger

Please expand more on the suggestion of using a slower baud rate on
the
serial line. I want to know more about machine characteristics. I
heartly welcome more knowledge since I’m experiencing hangs on two
different machine models. I’ll share what I’ve learned so far in
hopes
it will help.

I’ve found different results depending on the machine model of
the
target. I use the same the machine, a 2GHZ, as the debugger machine.

The debugee/target machine is either a 450 MHZ or a 1GHZ.
On
my old faithful target (450 MHZ Dual proc), for hangs using Windbg , I

send a kernel debug break again from the drop down list using the GUI
interface, not windbg command line entry. This causes a response. If
I
don’t do this and just try issuing more commands from the windbg
command
line, the machine does not respond. It is hung. This technique works
pretty well in most cases. On my troublesome newer machine (1GHZ), I
see a different behavior. The machine gets stuck/hung, and I’m not
sure
how to fix it. I’ll try the suggestions of different serial line
speeds. Both machines are running same OS, same set of drivers.

So, if you are seeing your machine hung in the debugger, you may
want
to see if that same behavior happens on another machine of different
characteristics. That gives you another piece of
information
in the problem solving.

Barb

-----Original Message-----
From: Sandy Spinrad [mailto:xxxxx@windows.microsoft.com]
Sent: Thursday, July 24, 2003 2:17 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Target machine hangs without breaking into
debugger

I could be stating the obvious here, but have you enabled driver
verifier on your driver, and any stacks that your driver is attached
to
(e.g. usb)?

It’s possible that the driver verifier might catch a failure before it

takes out the system (assuming that your driver is taking out the
system).

Also using checked builds of the kernel / corresponding stacks may
also
provide additional hints of what’s going wrong. Likewise testing on a

newer o/s release (assuming that you’re testing on an older o/s
release
like W2K) might also expose the problem.

Or it could be something that has to do with the debugger. Make sure
you’re using the latest windbg/kd. And if you’re running over serial
try a slower baud rate. If you’re running over 1394, try disabling
the
1394 port on the target system.

–Sandy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Linda Marcellus
Sent: Thursday, July 24, 2003 1:09 PM
To: Kernel Debugging Interest List
Subject: [windbg] Target machine hangs without breaking into debugger

Hi,

I’m having trouble using windbg (and even just kd) to debug a driver
that I’ve written.

If I don’t have windbg or kd running on my host, I can open a handle
to
my driver, and it can send bulk usb read requests down the usb stack
and
complete them without problems.

However, if I have windbg or kd running and have managed to break into

the debugger and load symbols etc (but haven’t set any breakpoints),
then I can open a handle to my driver, but as soon as the completion
routine runs for a bulk usb read, the target freezes and windbg (and
kd)
fails to break into the debugger. I know it’s stuck in the completion
routine, because of the debug output statements I see. My only
recourse
at that point is to physically reset the target, and I don’t get to
see
the information I’m interested in.

I’ve gotten about as far as I can debugging this driver using DbgPrint

statements and would like to actually use windbg (or even kd).

Any suggestions as to how I can get this working would be greatly
appreciated.

Thanks,
Linda


You are currently subscribed to windbg as:
xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: barbara.leahy@hp.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@nai.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: barbara.leahy@hp.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

We’ve found several cases where serial port communications between 2
machines (especially with 2 different machines) was not reliable at
higher baud rates (i.e. 57600 and above). When you have an unreliable
serial connection, then the kernel debugger will not behave as expected.

But because windbg perf is much better at higher baud rates, it is often
desirable to run at the highest possible baud rate. Personally, I
prefer to use a 1394 connection, but when that isn’t available, I try
using a serial connection at 115200 and work my way down if windbg isn’t
reliable enough.

Also keep in mind that it’s possible that a bug in a driver is causing
the system to crash which would have nothing to do with the baud rate.

Hope this helps,
–Sandy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Leahy, Barbara C
Sent: Monday, July 28, 2003 5:45 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Target machine hangs without breaking into
debugger

Yes, let me clarify my request.

What I’d like info on is why would a slower baud rate work
better than a faster one or would it. I know both machines must match
the baud rate and how to set the baud rate up. When I read the email
about baud rates, I got the impression that a slower baud rate may
worker better on some machines. Is this true? What I wanted to know is
if some machines will work at higher baud rates, but handle slower baud
rates better. Is there an ideal baud rate that works best with certain
machines? I want to know what the test guys have found works best.
Guess I’ll have to experiment on my own.

From my experience after updating my debugger today, what version of the
debugger I’m using makes a difference. I better keep the versions around
that I like.

Thanks, Barb

-----Original Message-----
From: xxxxx@NAI.com [mailto:xxxxx@NAI.com]
Sent: Friday, July 25, 2003 10:09 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Target machine hangs without breaking into
debugger

On host, you set the serial line baudrate. When you selected Kernel
Debug from File menu in Com tab.

On target, you set the baudrate in your boot.ini using /baudrate=xxxx

The baudrate specified at the host and target should be the same. Look
windbg documentation for valid baudrate values…

-Srin.

-----Original Message-----
From: Leahy, Barbara C [mailto:barbara.leahy@hp.com]
Sent: Friday, July 25, 2003 7:50 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Target machine hangs without breaking into
debugger

Please expand more on the suggestion of using a slower baud rate on
the
serial line. I want to know more about machine characteristics. I
heartly welcome more knowledge since I’m experiencing hangs on two
different machine models. I’ll share what I’ve learned so far in
hopes
it will help.

I’ve found different results depending on the machine model of
the
target. I use the same the machine, a 2GHZ, as the debugger machine.

The debugee/target machine is either a 450 MHZ or a 1GHZ.
On
my old faithful target (450 MHZ Dual proc), for hangs using Windbg , I

send a kernel debug break again from the drop down list using the GUI
interface, not windbg command line entry. This causes a response. If
I
don’t do this and just try issuing more commands from the windbg
command
line, the machine does not respond. It is hung. This technique works
pretty well in most cases. On my troublesome newer machine (1GHZ), I
see a different behavior. The machine gets stuck/hung, and I’m not
sure
how to fix it. I’ll try the suggestions of different serial line
speeds. Both machines are running same OS, same set of drivers.

So, if you are seeing your machine hung in the debugger, you may
want
to see if that same behavior happens on another machine of different
characteristics. That gives you another piece of
information
in the problem solving.

Barb

-----Original Message-----
From: Sandy Spinrad [mailto:xxxxx@windows.microsoft.com]
Sent: Thursday, July 24, 2003 2:17 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Target machine hangs without breaking into
debugger

I could be stating the obvious here, but have you enabled driver
verifier on your driver, and any stacks that your driver is attached
to
(e.g. usb)?

It’s possible that the driver verifier might catch a failure before it

takes out the system (assuming that your driver is taking out the
system).

Also using checked builds of the kernel / corresponding stacks may
also
provide additional hints of what’s going wrong. Likewise testing on a

newer o/s release (assuming that you’re testing on an older o/s
release
like W2K) might also expose the problem.

Or it could be something that has to do with the debugger. Make sure
you’re using the latest windbg/kd. And if you’re running over serial
try a slower baud rate. If you’re running over 1394, try disabling
the
1394 port on the target system.

–Sandy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Linda Marcellus
Sent: Thursday, July 24, 2003 1:09 PM
To: Kernel Debugging Interest List
Subject: [windbg] Target machine hangs without breaking into debugger

Hi,

I’m having trouble using windbg (and even just kd) to debug a driver
that I’ve written.

If I don’t have windbg or kd running on my host, I can open a handle
to
my driver, and it can send bulk usb read requests down the usb stack
and
complete them without problems.

However, if I have windbg or kd running and have managed to break into

the debugger and load symbols etc (but haven’t set any breakpoints),
then I can open a handle to my driver, but as soon as the completion
routine runs for a bulk usb read, the target freezes and windbg (and
kd)
fails to break into the debugger. I know it’s stuck in the completion
routine, because of the debug output statements I see. My only
recourse
at that point is to physically reset the target, and I don’t get to
see
the information I’m interested in.

I’ve gotten about as far as I can debugging this driver using DbgPrint

statements and would like to actually use windbg (or even kd).

Any suggestions as to how I can get this working would be greatly
appreciated.

Thanks,
Linda


You are currently subscribed to windbg as:
xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: barbara.leahy@hp.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@nai.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: barbara.leahy@hp.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Thank you!!! This gives me the answer to a question I’ve been asked and
never had an answer for about debugger preferences and reasons for them.
Reading your answer I now understand when to use kd and why. Thank you
again!!! :slight_smile:

Barb

-----Original Message-----
From: Sandy Spinrad [mailto:xxxxx@windows.microsoft.com]
Sent: Monday, July 28, 2003 5:56 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Target machine hangs without breaking into
debugger

We’ve found several cases where serial port communications between 2
machines (especially with 2 different machines) was not reliable at
higher baud rates (i.e. 57600 and above). When you have an unreliable
serial connection, then the kernel debugger will not behave as expected.

But because windbg perf is much better at higher baud rates, it is often
desirable to run at the highest possible baud rate. Personally, I
prefer to use a 1394 connection, but when that isn’t available, I try
using a serial connection at 115200 and work my way down if windbg isn’t
reliable enough.

Also keep in mind that it’s possible that a bug in a driver is causing
the system to crash which would have nothing to do with the baud rate.

Hope this helps,
–Sandy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Leahy, Barbara C
Sent: Monday, July 28, 2003 5:45 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Target machine hangs without breaking into
debugger

Yes, let me clarify my request.

What I’d like info on is why would a slower baud rate work
better than a faster one or would it. I know both machines must match
the baud rate and how to set the baud rate up. When I read the email
about baud rates, I got the impression that a slower baud rate may
worker better on some machines. Is this true? What I wanted to know is
if some machines will work at higher baud rates, but handle slower baud
rates better. Is there an ideal baud rate that works best with certain
machines? I want to know what the test guys have found works best.
Guess I’ll have to experiment on my own.

From my experience after updating my debugger today, what version of the
debugger I’m using makes a difference. I better keep the versions around
that I like.

Thanks, Barb

-----Original Message-----
From: xxxxx@NAI.com [mailto:xxxxx@NAI.com]
Sent: Friday, July 25, 2003 10:09 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Target machine hangs without breaking into
debugger

On host, you set the serial line baudrate. When you selected Kernel
Debug from File menu in Com tab.

On target, you set the baudrate in your boot.ini using /baudrate=xxxx

The baudrate specified at the host and target should be the same. Look
windbg documentation for valid baudrate values…

-Srin.

-----Original Message-----
From: Leahy, Barbara C [mailto:barbara.leahy@hp.com]
Sent: Friday, July 25, 2003 7:50 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Target machine hangs without breaking into
debugger

Please expand more on the suggestion of using a slower baud rate on
the
serial line. I want to know more about machine characteristics. I
heartly welcome more knowledge since I’m experiencing hangs on two
different machine models. I’ll share what I’ve learned so far in
hopes
it will help.

I’ve found different results depending on the machine model of
the
target. I use the same the machine, a 2GHZ, as the debugger machine.

The debugee/target machine is either a 450 MHZ or a 1GHZ.
On
my old faithful target (450 MHZ Dual proc), for hangs using Windbg , I

send a kernel debug break again from the drop down list using the GUI
interface, not windbg command line entry. This causes a response. If
I
don’t do this and just try issuing more commands from the windbg
command
line, the machine does not respond. It is hung. This technique works
pretty well in most cases. On my troublesome newer machine (1GHZ), I
see a different behavior. The machine gets stuck/hung, and I’m not
sure
how to fix it. I’ll try the suggestions of different serial line
speeds. Both machines are running same OS, same set of drivers.

So, if you are seeing your machine hung in the debugger, you may
want
to see if that same behavior happens on another machine of different
characteristics. That gives you another piece of
information
in the problem solving.

Barb

-----Original Message-----
From: Sandy Spinrad [mailto:xxxxx@windows.microsoft.com]
Sent: Thursday, July 24, 2003 2:17 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Target machine hangs without breaking into
debugger

I could be stating the obvious here, but have you enabled driver
verifier on your driver, and any stacks that your driver is attached
to
(e.g. usb)?

It’s possible that the driver verifier might catch a failure before it

takes out the system (assuming that your driver is taking out the
system).

Also using checked builds of the kernel / corresponding stacks may
also
provide additional hints of what’s going wrong. Likewise testing on a

newer o/s release (assuming that you’re testing on an older o/s
release
like W2K) might also expose the problem.

Or it could be something that has to do with the debugger. Make sure
you’re using the latest windbg/kd. And if you’re running over serial
try a slower baud rate. If you’re running over 1394, try disabling
the
1394 port on the target system.

–Sandy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Linda Marcellus
Sent: Thursday, July 24, 2003 1:09 PM
To: Kernel Debugging Interest List
Subject: [windbg] Target machine hangs without breaking into debugger

Hi,

I’m having trouble using windbg (and even just kd) to debug a driver
that I’ve written.

If I don’t have windbg or kd running on my host, I can open a handle
to
my driver, and it can send bulk usb read requests down the usb stack
and
complete them without problems.

However, if I have windbg or kd running and have managed to break into

the debugger and load symbols etc (but haven’t set any breakpoints),
then I can open a handle to my driver, but as soon as the completion
routine runs for a bulk usb read, the target freezes and windbg (and
kd)
fails to break into the debugger. I know it’s stuck in the completion
routine, because of the debug output statements I see. My only
recourse
at that point is to physically reset the target, and I don’t get to
see
the information I’m interested in.

I’ve gotten about as far as I can debugging this driver using DbgPrint

statements and would like to actually use windbg (or even kd).

Any suggestions as to how I can get this working would be greatly
appreciated.

Thanks,
Linda


You are currently subscribed to windbg as:
xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: barbara.leahy@hp.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@nai.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: barbara.leahy@hp.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: barbara.leahy@hp.com
To unsubscribe send a blank email to xxxxx@lists.osr.com