WinDbg 3.0.0010.0 User Mode/C++ symbol issues

I caught a user mode exception while connected to a target machine through
the debug port. I had symbols for the offending app and tred stepping
through the code. However the local/global variable symbolics were pretty
much useless. The symbols did not resolve correctly, and I was unable to
cast any memory locations to objects for viewing that way.

I also tried this with a memory dump created by Dr Watson.

I was using debug symbols generated by vs6.0sp4 in a debug build.

Any information on why this is happening/corraboration it’s a bug?


You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Chances are the symbols you were using do not match the binaries, or
there was some other symbol load problem.

You can use “!sym noisy” or -n on the cmd line to turn on verbose symbol
loading. This may help you pinpoint the cause of the problem.

If you are convinced that it is a debugger bug, then the easiest way for
us to debug would be for you to zip up the dump & symbols and send them
to us.

-----Original Message-----
From: xxxxx@emc.com [mailto:xxxxx@emc.com]
Sent: Wednesday, June 27, 2001 6:00 PM
To: Kernel Debugging Interest List
Subject: [windbg] WinDbg 3.0.0010.0 User Mode/C++ symbol issues

I caught a user mode exception while connected to a target machine
through
the debug port. I had symbols for the offending app and tred stepping
through the code. However the local/global variable symbolics were
pretty
much useless. The symbols did not resolve correctly, and I was unable
to
cast any memory locations to objects for viewing that way.

I also tried this with a memory dump created by Dr Watson.

I was using debug symbols generated by vs6.0sp4 in a debug build.

Any information on why this is happening/corraboration it’s a bug?


You are currently subscribed to windbg as: xxxxx@microsoft.com
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OK here is the output of a ‘.reload’ with ‘!sym noisy’ set. Steps prior to
the command were:

  1. Open windbg from start menu
  2. Set sympath via menu to 'c:\temp;symsrv*symsrv.dll*\\symsrv
    3) issue ‘.reload’

    WARNING: Teb 1 pointer is NULL - defaulting to 7ffdd000
    …DBGHELP: diaLocatePDB-> Looking for c:\temp\symbols\dll\powapi.pdb…
    file not found
    DBGHELP: diaLocatePDB-> Looking for c:\temp\dll\powapi.pdb… file not found
    DBGHELP: diaLocatePDB-> Looking for c:\temp\powapi.pdb… unknown pdb sig OK
    WARNING: Unable to verify checksum for powapi.dll

    DBGHELP: diaLocatePDB-> Looking for c:\temp\symbols\exe\powsrv.pdb… file
    not found
    DBGHELP: diaLocatePDB-> Looking for c:\temp\exe\powsrv.pdb… file not found
    DBGHELP: diaLocatePDB-> Looking for c:\temp\powsrv.pdb… unknown pdb sig OK
    WARNING: Unable to verify checksum for powsrv.exe
    DBGHELP: FindDebugInfoFileEx-> Looking for
    c:\temp\symbols\dll\ADVAPI32.dbg… path not found
    SYMSRV: \\symsrv\ADVAPI32.dbg\375845103f000\ADVAPI32.dbg - OK

    At this point the locals are incorrect, but by looking at the disassembly I
    can use watch to cast the views correctly.

    I verified the symbols by scanning the memory dump for our embedded version
    string and verifying that the pdb was correct for the file.

    Thanks,
    Dan

    > -----Original Message-----
    > From: Nathan Nesbit [mailto:xxxxx@windows.microsoft.com]
    > Sent: Thursday, June 28, 2001 1:24 PM
    > To: Kernel Debugging Interest List
    > Cc: green, daniel
    > Subject: [windbg] RE: WinDbg 3.0.0010.0 User Mode/C++ symbol issues
    >
    >
    > Chances are the symbols you were using do not match the binaries, or
    > there was some other symbol load problem.
    >
    > You can use “!sym noisy” or -n on the cmd line to turn on
    > verbose symbol
    > loading. This may help you pinpoint the cause of the problem.
    >
    > If you are convinced that it is a debugger bug, then the
    > easiest way for
    > us to debug would be for you to zip up the dump & symbols and
    > send them
    > to us.
    >
    > -----Original Message-----
    > From: xxxxx@emc.com [mailto:xxxxx@emc.com]
    > Sent: Wednesday, June 27, 2001 6:00 PM
    > To: Kernel Debugging Interest List
    > Subject: [windbg] WinDbg 3.0.0010.0 User Mode/C++ symbol issues
    >
    > I caught a user mode exception while connected to a target machine
    > through
    > the debug port. I had symbols for the offending app and tred
    > stepping
    > through the code. However the local/global variable symbolics were
    > pretty
    > much useless. The symbols did not resolve correctly, and I was unable
    > to
    > cast any memory locations to objects for viewing that way.
    >
    > I also tried this with a memory dump created by Dr Watson.
    >
    > I was using debug symbols generated by vs6.0sp4 in a debug build.
    >
    > Any information on why this is happening/corraboration it’s a bug?
    >
    > —
    > You are currently subscribed to windbg as: xxxxx@microsoft.com
    > To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com
    >
    > —
    > You are currently subscribed to windbg as: xxxxx@emc.com
    > To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com
    >


    You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
    To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

DBGHELP: diaLocatePDB-> Looking for c:\temp\powapi.pdb… unknown pdb
sig OK
*** WARNING: Unable to verify checksum for powapi.dll

This message means that the information the debugger needs to verify if
the symbols match the binary is unavailable. The information is
probably paged out.

Since your locals/globals are incorrect this indicates to me that they
probably don’t really match. Compare the timestamps on the PDB and the
binary, they should be the same. I bet they are different.

-----Original Message-----
From: green, daniel [mailto:xxxxx@emc.com]
Sent: Friday, June 29, 2001 4:24 AM
To: Kernel Debugging Interest List
Cc: Nathan Nesbit
Subject: [windbg] RE: WinDbg 3.0.0010.0 User Mode/C++ symbol issues

OK here is the output of a ‘.reload’ with ‘!sym noisy’ set. Steps prior
to
the command were:

  1. Open windbg from start menu
  2. Set sympath via menu to 'c:\temp;symsrv*symsrv.dll*\\symsrv
    3) issue ‘.reload’

    WARNING: Teb 1 pointer is NULL - defaulting to 7ffdd000
    …DBGHELP: diaLocatePDB-> Looking for
    c:\temp\symbols\dll\powapi.pdb…
    file not found
    DBGHELP: diaLocatePDB-> Looking for c:\temp\dll\powapi.pdb… file not
    found
    DBGHELP: diaLocatePDB-> Looking for c:\temp\powapi.pdb… unknown pdb
    sig OK
    WARNING: Unable to verify checksum for powapi.dll

    DBGHELP: diaLocatePDB-> Looking for c:\temp\symbols\exe\powsrv.pdb…
    file
    not found
    DBGHELP: diaLocatePDB-> Looking for c:\temp\exe\powsrv.pdb… file not
    found
    DBGHELP: diaLocatePDB-> Looking for c:\temp\powsrv.pdb… unknown pdb
    sig OK
    WARNING: Unable to verify checksum for powsrv.exe
    DBGHELP: FindDebugInfoFileEx-> Looking for
    c:\temp\symbols\dll\ADVAPI32.dbg… path not found
    SYMSRV: \\symsrv\ADVAPI32.dbg\375845103f000\ADVAPI32.dbg - OK

    At this point the locals are incorrect, but by looking at the
    disassembly I
    can use watch to cast the views correctly.

    I verified the symbols by scanning the memory dump for our embedded
    version
    string and verifying that the pdb was correct for the file.

    Thanks,
    Dan

    > -----Original Message-----
    > From: Nathan Nesbit [mailto:xxxxx@windows.microsoft.com]
    > Sent: Thursday, June 28, 2001 1:24 PM
    > To: Kernel Debugging Interest List
    > Cc: green, daniel
    > Subject: [windbg] RE: WinDbg 3.0.0010.0 User Mode/C++ symbol issues
    >
    >
    > Chances are the symbols you were using do not match the binaries, or
    > there was some other symbol load problem.
    >
    > You can use “!sym noisy” or -n on the cmd line to turn on
    > verbose symbol
    > loading. This may help you pinpoint the cause of the problem.
    >
    > If you are convinced that it is a debugger bug, then the
    > easiest way for
    > us to debug would be for you to zip up the dump & symbols and
    > send them
    > to us.
    >
    > -----Original Message-----
    > From: xxxxx@emc.com [mailto:xxxxx@emc.com]
    > Sent: Wednesday, June 27, 2001 6:00 PM
    > To: Kernel Debugging Interest List
    > Subject: [windbg] WinDbg 3.0.0010.0 User Mode/C++ symbol issues
    >
    > I caught a user mode exception while connected to a target machine
    > through
    > the debug port. I had symbols for the offending app and tred
    > stepping
    > through the code. However the local/global variable symbolics were
    > pretty
    > much useless. The symbols did not resolve correctly, and I was unable
    > to
    > cast any memory locations to objects for viewing that way.
    >
    > I also tried this with a memory dump created by Dr Watson.
    >
    > I was using debug symbols generated by vs6.0sp4 in a debug build.
    >
    > Any information on why this is happening/corraboration it’s a bug?
    >
    > —
    > You are currently subscribed to windbg as: xxxxx@microsoft.com
    > To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com
    >
    > —
    > You are currently subscribed to windbg as: xxxxx@emc.com
    > To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com
    >


    You are currently subscribed to windbg as: xxxxx@microsoft.com
    To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com


    You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
    To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

I took this off the windbg list since it doesn’t seem relevant to the wider
audience. Feel free to add it back if you think it’s appropriate.

I verified the timestamp and build number of the crash dump I originally saw
the problem in and they match up.
I did find that this was a retail build, and most of the functions in the
call stack were FPO, maybe this is why the locals are not resolving.

I re-created the problem on Friday afternoon, but this time the locals seem
to match up. But I still get the checksum errors.

Just to re-iterate everything:

I am analyzing a user mode crash dump created by drwtsn32.exe

The size of the memory dump is 10.3 MB

I do a !sym noisy and get errors during symbol resolution

*** WARNING: Unable to verify checksum for EmcPowApi.dll
*** WARNING: Unable to verify checksum for PowAdm.exe

I went and checked the file time stamps of these two binaries and they are
the same as their pdb files.

At this point I’m not going to pursue this further, but I would like to know
why the checksum errors are appearing.

Thanks,
Dan

-----Original Message-----
From: Nathan Nesbit [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, June 29, 2001 6:42 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: WinDbg 3.0.0010.0 User Mode/C++ symbol issues

DBGHELP: diaLocatePDB-> Looking for c:\temp\powapi.pdb… unknown pdb
sig OK
*** WARNING: Unable to verify checksum for powapi.dll

This message means that the information the debugger needs to
verify if
the symbols match the binary is unavailable. The information is
probably paged out.

Since your locals/globals are incorrect this indicates to me that they
probably don’t really match. Compare the timestamps on the
PDB and the
binary, they should be the same. I bet they are different.

-----Original Message-----
From: green, daniel [mailto:xxxxx@emc.com]
Sent: Friday, June 29, 2001 4:24 AM
To: Kernel Debugging Interest List
Cc: Nathan Nesbit
Subject: [windbg] RE: WinDbg 3.0.0010.0 User Mode/C++ symbol issues

OK here is the output of a ‘.reload’ with ‘!sym noisy’ set.
Steps prior
to
the command were:

  1. Open windbg from start menu
  2. Set sympath via menu to
    'c:\temp;symsrv*symsrv.dll*\\symsrv
    > 3) issue ‘.reload’
    >
    > WARNING: Teb 1 pointer is NULL - defaulting to 7ffdd000
    > …DBGHELP: diaLocatePDB-> Looking for
    > c:\temp\symbols\dll\powapi.pdb…
    > file not found
    > DBGHELP: diaLocatePDB-> Looking for c:\temp\dll\powapi.pdb… file not
    > found
    > DBGHELP: diaLocatePDB-> Looking for c:\temp\powapi.pdb… unknown pdb
    > sig OK
    > WARNING: Unable to verify checksum for powapi.dll
    > …
    > DBGHELP: diaLocatePDB-> Looking for c:\temp\symbols\exe\powsrv.pdb…
    > file
    > not found
    > DBGHELP: diaLocatePDB-> Looking for c:\temp\exe\powsrv.pdb… file not
    > found
    > DBGHELP: diaLocatePDB-> Looking for c:\temp\powsrv.pdb… unknown pdb
    > sig OK
    >
    WARNING: Unable to verify checksum for powsrv.exe
    > DBGHELP: FindDebugInfoFileEx-> Looking for
    > c:\temp\symbols\dll\ADVAPI32.dbg… path not found
    > SYMSRV:
    > \\symsrv\ADVAPI32.dbg\375845103f000\ADVAPI32.dbg - OK
    >
    > At this point the locals are incorrect, but by looking at the
    > disassembly I
    > can use watch to cast the views correctly.
    >
    > I verified the symbols by scanning the memory dump for our embedded
    > version
    > string and verifying that the pdb was correct for the file.
    >
    > Thanks,
    > Dan
    >
    > > -----Original Message-----
    > > From: Nathan Nesbit [mailto:xxxxx@windows.microsoft.com]
    > > Sent: Thursday, June 28, 2001 1:24 PM
    > > To: Kernel Debugging Interest List
    > > Cc: green, daniel
    > > Subject: [windbg] RE: WinDbg 3.0.0010.0 User Mode/C++ symbol issues
    > >
    > >
    > > Chances are the symbols you were using do not match the binaries, or
    > > there was some other symbol load problem.
    > >
    > > You can use “!sym noisy” or -n on the cmd line to turn on
    > > verbose symbol
    > > loading. This may help you pinpoint the cause of the problem.
    > >
    > > If you are convinced that it is a debugger bug, then the
    > > easiest way for
    > > us to debug would be for you to zip up the dump & symbols and
    > > send them
    > > to us.
    > >
    > > -----Original Message-----
    > > From: xxxxx@emc.com [mailto:xxxxx@emc.com]
    > > Sent: Wednesday, June 27, 2001 6:00 PM
    > > To: Kernel Debugging Interest List
    > > Subject: [windbg] WinDbg 3.0.0010.0 User Mode/C++ symbol issues
    > >
    > > I caught a user mode exception while connected to a target machine
    > > through
    > > the debug port. I had symbols for the offending app and tred
    > > stepping
    > > through the code. However the local/global variable symbolics were
    > > pretty
    > > much useless. The symbols did not resolve correctly, and I
    > was unable
    > > to
    > > cast any memory locations to objects for viewing that way.
    > >
    > > I also tried this with a memory dump created by Dr Watson.
    > >
    > > I was using debug symbols generated by vs6.0sp4 in a debug build.
    > >
    > > Any information on why this is happening/corraboration it’s a bug?
    > >
    > > —
    > > You are currently subscribed to windbg as: xxxxx@microsoft.com
    > > To unsubscribe send a blank email to
    > leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com
    > >
    > > —
    > > You are currently subscribed to windbg as: xxxxx@emc.com
    > > To unsubscribe send a blank email to
    > leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com
    > >
    >
    > —
    > You are currently subscribed to windbg as: xxxxx@microsoft.com
    > To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com
    >
    > —
    > You are currently subscribed to windbg as: xxxxx@emc.com
    > To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com
    >


    You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
    To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Optimized code will totally mess up local variables. This is because
there is not enough info in the PDB. Because it is a limitation in the
symbols all debuggers suffer from this issue.

As for why the checksum can’t be validated for those modules on that
dump, I have no idea. We would have to see the dump in order to figure
it out. Perhaps the dump is corrupt in some way.

-----Original Message-----
From: green, daniel [mailto:xxxxx@emc.com]
Sent: Monday, July 02, 2001 5:00 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: WinDbg 3.0.0010.0 User Mode/C++ symbol issues

I took this off the windbg list since it doesn’t seem relevant to the
wider
audience. Feel free to add it back if you think it’s appropriate.

I verified the timestamp and build number of the crash dump I originally
saw
the problem in and they match up.
I did find that this was a retail build, and most of the functions in
the
call stack were FPO, maybe this is why the locals are not resolving.

I re-created the problem on Friday afternoon, but this time the locals
seem
to match up. But I still get the checksum errors.

Just to re-iterate everything:

I am analyzing a user mode crash dump created by drwtsn32.exe

The size of the memory dump is 10.3 MB

I do a !sym noisy and get errors during symbol resolution

*** WARNING: Unable to verify checksum for EmcPowApi.dll
*** WARNING: Unable to verify checksum for PowAdm.exe

I went and checked the file time stamps of these two binaries and they
are
the same as their pdb files.

At this point I’m not going to pursue this further, but I would like to
know
why the checksum errors are appearing.

Thanks,
Dan

-----Original Message-----
From: Nathan Nesbit [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, June 29, 2001 6:42 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: WinDbg 3.0.0010.0 User Mode/C++ symbol issues

DBGHELP: diaLocatePDB-> Looking for c:\temp\powapi.pdb… unknown pdb
sig OK
*** WARNING: Unable to verify checksum for powapi.dll

This message means that the information the debugger needs to
verify if
the symbols match the binary is unavailable. The information is
probably paged out.

Since your locals/globals are incorrect this indicates to me that they
probably don’t really match. Compare the timestamps on the
PDB and the
binary, they should be the same. I bet they are different.

-----Original Message-----
From: green, daniel [mailto:xxxxx@emc.com]
Sent: Friday, June 29, 2001 4:24 AM
To: Kernel Debugging Interest List
Cc: Nathan Nesbit
Subject: [windbg] RE: WinDbg 3.0.0010.0 User Mode/C++ symbol issues

OK here is the output of a ‘.reload’ with ‘!sym noisy’ set.
Steps prior
to
the command were:

  1. Open windbg from start menu
  2. Set sympath via menu to
    'c:\temp;symsrv*symsrv.dll*\\symsrv
    > 3) issue ‘.reload’
    >
    > WARNING: Teb 1 pointer is NULL - defaulting to 7ffdd000
    > …DBGHELP: diaLocatePDB-> Looking for
    > c:\temp\symbols\dll\powapi.pdb…
    > file not found
    > DBGHELP: diaLocatePDB-> Looking for c:\temp\dll\powapi.pdb… file not
    > found
    > DBGHELP: diaLocatePDB-> Looking for c:\temp\powapi.pdb… unknown pdb
    > sig OK
    > WARNING: Unable to verify checksum for powapi.dll
    > …
    > DBGHELP: diaLocatePDB-> Looking for c:\temp\symbols\exe\powsrv.pdb…
    > file
    > not found
    > DBGHELP: diaLocatePDB-> Looking for c:\temp\exe\powsrv.pdb… file not
    > found
    > DBGHELP: diaLocatePDB-> Looking for c:\temp\powsrv.pdb… unknown pdb
    > sig OK
    >
    WARNING: Unable to verify checksum for powsrv.exe
    > DBGHELP: FindDebugInfoFileEx-> Looking for
    > c:\temp\symbols\dll\ADVAPI32.dbg… path not found
    > SYMSRV:
    > \\symsrv\ADVAPI32.dbg\375845103f000\ADVAPI32.dbg - OK
    >
    > At this point the locals are incorrect, but by looking at the
    > disassembly I
    > can use watch to cast the views correctly.
    >
    > I verified the symbols by scanning the memory dump for our embedded
    > version
    > string and verifying that the pdb was correct for the file.
    >
    > Thanks,
    > Dan
    >
    > > -----Original Message-----
    > > From: Nathan Nesbit [mailto:xxxxx@windows.microsoft.com]
    > > Sent: Thursday, June 28, 2001 1:24 PM
    > > To: Kernel Debugging Interest List
    > > Cc: green, daniel
    > > Subject: [windbg] RE: WinDbg 3.0.0010.0 User Mode/C++ symbol issues
    > >
    > >
    > > Chances are the symbols you were using do not match the binaries, or
    > > there was some other symbol load problem.
    > >
    > > You can use “!sym noisy” or -n on the cmd line to turn on
    > > verbose symbol
    > > loading. This may help you pinpoint the cause of the problem.
    > >
    > > If you are convinced that it is a debugger bug, then the
    > > easiest way for
    > > us to debug would be for you to zip up the dump & symbols and
    > > send them
    > > to us.
    > >
    > > -----Original Message-----
    > > From: xxxxx@emc.com [mailto:xxxxx@emc.com]
    > > Sent: Wednesday, June 27, 2001 6:00 PM
    > > To: Kernel Debugging Interest List
    > > Subject: [windbg] WinDbg 3.0.0010.0 User Mode/C++ symbol issues
    > >
    > > I caught a user mode exception while connected to a target machine
    > > through
    > > the debug port. I had symbols for the offending app and tred
    > > stepping
    > > through the code. However the local/global variable symbolics were
    > > pretty
    > > much useless. The symbols did not resolve correctly, and I
    > was unable
    > > to
    > > cast any memory locations to objects for viewing that way.
    > >
    > > I also tried this with a memory dump created by Dr Watson.
    > >
    > > I was using debug symbols generated by vs6.0sp4 in a debug build.
    > >
    > > Any information on why this is happening/corraboration it’s a bug?
    > >
    > > —
    > > You are currently subscribed to windbg as: xxxxx@microsoft.com
    > > To unsubscribe send a blank email to
    > leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com
    > >
    > > —
    > > You are currently subscribed to windbg as: xxxxx@emc.com
    > > To unsubscribe send a blank email to
    > leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com
    > >
    >
    > —
    > You are currently subscribed to windbg as: xxxxx@microsoft.com
    > To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com
    >
    > —
    > You are currently subscribed to windbg as: xxxxx@emc.com
    > To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com
    >


    You are currently subscribed to windbg as: xxxxx@microsoft.com
    To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com


    You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
    To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

I alway place the pdb files using the following sturcture and seems work
for my cases.

e.g c:\temp\symbols\dll\powapi.pdb
c:\temp\symbols\exe\powsrv.pdb
c:\temp\symbols\sys..


You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com