I have a strange problem, my driver runs without a crash normally,
however when windbg is connected this is what i see
Breakpoint 0’s offset expression evaluation failed.
Check for invalid symbols or bad syntax.
WaitForEvent failed
nt+0x59082:
80537082 8945fc mov [ebp-0x4],eax
kd> bl
0 du 0001 (0001) (dummmy!DriverEntry)
I have the correct symbols, and path set in the debugger, and this
break point is disabled, then why does the kernel panic?
Let me guess … you were unlucky enough to install 6.4 or 6.5? This is the
same behavior I have seen with versions 6.4 and 6.5. It seems that these
versions of WinDbg are easily confused about where and how to use symbols,
even going so far as to have an unrecognizable breakpoint that you cannot
get around until you provide the proper symbology. Which sometimes you can’t
because the symbol file you are trying to replace is held by WinDbg causing
your build to bomb when it creates the PDB file. Doing a “!reload -u” has to
large a chance on 6.4 and 6.5 of not working so your only alternative is to
kill WinDbg, build the symbols, and the restart… Even booting the target
and doing the host build right after the target resets, will not allow the
PDB file to be built. I have so spent much time trying to get symbols
usable, that I finally said screw it and fell back to 6.3. I would rather
debug my code than debug a debugger.
To the WinDbg developers:
I am more than willing to tell you what my target environment is to permit
you to stage a system that evidences the same problem. I’ll even provide
dumps and other information I can acquire, within reason, tat may help you
resolve issues. However, an honest evaluation of what I have seen so far
with 6.4 and 6.5 is that there was insufficient testing before the release.
I will provide what info I can, but frankly, debugging the debugger has cost
me time over the past two weeks that I can ill afford, and unfortunately
schedules don’t have places in them for faulty WinDbgs. (Sometimes my boss
thinks I am a wind bag.)
but this thread best belongs in the WinDbg forum.
–
The personal opinion of
Gary G. Little
“Bedanto” wrote in message news:xxxxx@ntdev…
I have a strange problem, my driver runs without a crash normally,
however when windbg is connected this is what i see
Breakpoint 0’s offset expression evaluation failed.
Check for invalid symbols or bad syntax.
WaitForEvent failed
nt+0x59082:
80537082 8945fc mov [ebp-0x4],eax
kd> bl
0 du 0001 (0001) (dummmy!DriverEntry)
I have the correct symbols, and path set in the debugger, and this
break point is disabled, then why does the kernel panic?
I setup my development builds and my debugger so that the target
directory is NOT where I point windbg at to find the symbols for test
drivers/exes. That way the worst case is that windbg is looking at the
wrong symbols and not that I can’t build because the pdb file is locked.
I just have to remember to refresh the test directory as well as the
target system. That is error prone of course, but I’ve taken care of
that for all but boot drivers by using a map file.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Thursday, August 25, 2005 2:33 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] winDbg causing problems
Let me guess … you were unlucky enough to install 6.4 or 6.5? This is
the
same behavior I have seen with versions 6.4 and 6.5. It seems that these
versions of WinDbg are easily confused about where and how to use
symbols,
even going so far as to have an unrecognizable breakpoint that you
cannot
get around until you provide the proper symbology. Which sometimes you
can’t
because the symbol file you are trying to replace is held by WinDbg
causing
your build to bomb when it creates the PDB file. Doing a “!reload -u”
has to
large a chance on 6.4 and 6.5 of not working so your only alternative is
to
kill WinDbg, build the symbols, and the restart… Even booting the
target
and doing the host build right after the target resets, will not allow
the
PDB file to be built. I have so spent much time trying to get symbols
usable, that I finally said screw it and fell back to 6.3. I would
rather
debug my code than debug a debugger.
To the WinDbg developers:
I am more than willing to tell you what my target environment is to
permit
you to stage a system that evidences the same problem. I’ll even provide
dumps and other information I can acquire, within reason, tat may help
you
resolve issues. However, an honest evaluation of what I have seen so far
with 6.4 and 6.5 is that there was insufficient testing before the
release.
I will provide what info I can, but frankly, debugging the debugger has
cost
me time over the past two weeks that I can ill afford, and
unfortunately
schedules don’t have places in them for faulty WinDbgs. (Sometimes my
boss
thinks I am a wind bag.)
but this thread best belongs in the WinDbg forum.
–
The personal opinion of
Gary G. Little
“Bedanto” wrote in message news:xxxxx@ntdev…
I have a strange problem, my driver runs without a crash normally,
however when windbg is connected this is what i see
Breakpoint 0’s offset expression evaluation failed.
Check for invalid symbols or bad syntax.
WaitForEvent failed
nt+0x59082:
80537082 8945fc mov [ebp-0x4],eax
kd> bl
0 du 0001 (0001) (dummmy!DriverEntry)
I have the correct symbols, and path set in the debugger, and this
break point is disabled, then why does the kernel panic?
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I do the same.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Roddy, Mark”
To: “Windows System Software Devs Interest List”
Sent: Thursday, August 25, 2005 11:14 PM
Subject: RE: [ntdev] winDbg causing problems
I setup my development builds and my debugger so that the target
directory is NOT where I point windbg at to find the symbols for test
drivers/exes. That way the worst case is that windbg is looking at the
wrong symbols and not that I can’t build because the pdb file is locked.
I just have to remember to refresh the test directory as well as the
target system. That is error prone of course, but I’ve taken care of
that for all but boot drivers by using a map file.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Thursday, August 25, 2005 2:33 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] winDbg causing problems
Let me guess … you were unlucky enough to install 6.4 or 6.5? This is
the
same behavior I have seen with versions 6.4 and 6.5. It seems that these
versions of WinDbg are easily confused about where and how to use
symbols,
even going so far as to have an unrecognizable breakpoint that you
cannot
get around until you provide the proper symbology. Which sometimes you
can’t
because the symbol file you are trying to replace is held by WinDbg
causing
your build to bomb when it creates the PDB file. Doing a “!reload -u”
has to
large a chance on 6.4 and 6.5 of not working so your only alternative is
to
kill WinDbg, build the symbols, and the restart… Even booting the
target
and doing the host build right after the target resets, will not allow
the
PDB file to be built. I have so spent much time trying to get symbols
usable, that I finally said screw it and fell back to 6.3. I would
rather
debug my code than debug a debugger.
To the WinDbg developers:
I am more than willing to tell you what my target environment is to
permit
you to stage a system that evidences the same problem. I’ll even provide
dumps and other information I can acquire, within reason, tat may help
you
resolve issues. However, an honest evaluation of what I have seen so far
with 6.4 and 6.5 is that there was insufficient testing before the
release.
I will provide what info I can, but frankly, debugging the debugger has
cost
me time over the past two weeks that I can ill afford, and
unfortunately
schedules don’t have places in them for faulty WinDbgs. (Sometimes my
boss
thinks I am a wind bag.)
but this thread best belongs in the WinDbg forum.
–
The personal opinion of
Gary G. Little
“Bedanto” wrote in message news:xxxxx@ntdev…
I have a strange problem, my driver runs without a crash normally,
however when windbg is connected this is what i see
Breakpoint 0’s offset expression evaluation failed.
Check for invalid symbols or bad syntax.
WaitForEvent failed
nt+0x59082:
80537082 8945fc mov [ebp-0x4],eax
kd> bl
0 du 0001 (0001) (dummmy!DriverEntry)
I have the correct symbols, and path set in the debugger, and this
break point is disabled, then why does the kernel panic?
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Until 6.4/6.5 it really wasn’t a problem. In 6.3 I find that “!reload -u
” is quite effective in releasing the PDB file. In 6.4/6.5 that
simply does not work reliably. The only reliable did I did find was to close
WinDbg, build and then restart it.6.4/6.5 are simply not worth the time or
effort to try to use them.
–
Gary G. Little
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> I do the same.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Roddy, Mark”
> To: “Windows System Software Devs Interest List”
> Sent: Thursday, August 25, 2005 11:14 PM
> Subject: RE: [ntdev] winDbg causing problems
>
>
> I setup my development builds and my debugger so that the target
> directory is NOT where I point windbg at to find the symbols for test
> drivers/exes. That way the worst case is that windbg is looking at the
> wrong symbols and not that I can’t build because the pdb file is locked.
> I just have to remember to refresh the test directory as well as the
> target system. That is error prone of course, but I’ve taken care of
> that for all but boot drivers by using a map file.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
> Sent: Thursday, August 25, 2005 2:33 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] winDbg causing problems
>
> Let me guess … you were unlucky enough to install 6.4 or 6.5? This is
> the
> same behavior I have seen with versions 6.4 and 6.5. It seems that these
>
> versions of WinDbg are easily confused about where and how to use
> symbols,
> even going so far as to have an unrecognizable breakpoint that you
> cannot
> get around until you provide the proper symbology. Which sometimes you
> can’t
> because the symbol file you are trying to replace is held by WinDbg
> causing
> your build to bomb when it creates the PDB file. Doing a “!reload -u”
> has to
> large a chance on 6.4 and 6.5 of not working so your only alternative is
> to
> kill WinDbg, build the symbols, and the restart… Even booting the
> target
> and doing the host build right after the target resets, will not allow
> the
> PDB file to be built. I have so spent much time trying to get symbols
> usable, that I finally said screw it and fell back to 6.3. I would
> rather
> debug my code than debug a debugger.
>
> To the WinDbg developers:
>
> I am more than willing to tell you what my target environment is to
> permit
> you to stage a system that evidences the same problem. I’ll even provide
>
> dumps and other information I can acquire, within reason, tat may help
> you
> resolve issues. However, an honest evaluation of what I have seen so far
>
> with 6.4 and 6.5 is that there was insufficient testing before the
> release.
> I will provide what info I can, but frankly, debugging the debugger has
> cost
> me time over the past two weeks that I can ill afford, and
> unfortunately
> schedules don’t have places in them for faulty WinDbgs. (Sometimes my
> boss
> thinks I am a wind bag.)
>
> but this thread best belongs in the WinDbg forum.
>
> –
> The personal opinion of
> Gary G. Little
>
> “Bedanto” wrote in message news:xxxxx@ntdev…
> I have a strange problem, my driver runs without a crash normally,
> however when windbg is connected this is what i see
>
> Breakpoint 0’s offset expression evaluation failed.
> Check for invalid symbols or bad syntax.
> WaitForEvent failed
> nt+0x59082:
> 80537082 8945fc mov [ebp-0x4],eax
> kd> bl
> 0 du 0001 (0001) (dummmy!DriverEntry)
>
>
>
> I have the correct symbols, and path set in the debugger, and this
> break point is disabled, then why does the kernel panic?
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@stratus.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
ok, so the debgger is buggy! Well, where can I find winDbg 6.3?
On 8/26/05, Gary G. Little wrote:
> Until 6.4/6.5 it really wasn’t a problem. In 6.3 I find that “!reload -u
> ” is quite effective in releasing the PDB file. In 6.4/6.5 that
> simply does not work reliably. The only reliable did I did find was to close
> WinDbg, build and then restart it.6.4/6.5 are simply not worth the time or
> effort to try to use them.
>
> –
> Gary G. Little
>
> “Maxim S. Shatskih” wrote in message
> news:xxxxx@ntdev…
> > I do the same.
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> > ----- Original Message -----
> > From: “Roddy, Mark”
> > To: “Windows System Software Devs Interest List”
> > Sent: Thursday, August 25, 2005 11:14 PM
> > Subject: RE: [ntdev] winDbg causing problems
> >
> >
> > I setup my development builds and my debugger so that the target
> > directory is NOT where I point windbg at to find the symbols for test
> > drivers/exes. That way the worst case is that windbg is looking at the
> > wrong symbols and not that I can’t build because the pdb file is locked.
> > I just have to remember to refresh the test directory as well as the
> > target system. That is error prone of course, but I’ve taken care of
> > that for all but boot drivers by using a map file.
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
> > Sent: Thursday, August 25, 2005 2:33 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re:[ntdev] winDbg causing problems
> >
> > Let me guess … you were unlucky enough to install 6.4 or 6.5? This is
> > the
> > same behavior I have seen with versions 6.4 and 6.5. It seems that these
> >
> > versions of WinDbg are easily confused about where and how to use
> > symbols,
> > even going so far as to have an unrecognizable breakpoint that you
> > cannot
> > get around until you provide the proper symbology. Which sometimes you
> > can’t
> > because the symbol file you are trying to replace is held by WinDbg
> > causing
> > your build to bomb when it creates the PDB file. Doing a “!reload -u”
> > has to
> > large a chance on 6.4 and 6.5 of not working so your only alternative is
> > to
> > kill WinDbg, build the symbols, and the restart… Even booting the
> > target
> > and doing the host build right after the target resets, will not allow
> > the
> > PDB file to be built. I have so spent much time trying to get symbols
> > usable, that I finally said screw it and fell back to 6.3. I would
> > rather
> > debug my code than debug a debugger.
> >
> > To the WinDbg developers:
> >
> > I am more than willing to tell you what my target environment is to
> > permit
> > you to stage a system that evidences the same problem. I’ll even provide
> >
> > dumps and other information I can acquire, within reason, tat may help
> > you
> > resolve issues. However, an honest evaluation of what I have seen so far
> >
> > with 6.4 and 6.5 is that there was insufficient testing before the
> > release.
> > I will provide what info I can, but frankly, debugging the debugger has
> > cost
> > me time over the past two weeks that I can ill afford, and
> > unfortunately
> > schedules don’t have places in them for faulty WinDbgs. (Sometimes my
> > boss
> > thinks I am a wind bag.)
> >
> > but this thread best belongs in the WinDbg forum.
> >
> > –
> > The personal opinion of
> > Gary G. Little
> >
> > “Bedanto” wrote in message news:xxxxx@ntdev…
> > I have a strange problem, my driver runs without a crash normally,
> > however when windbg is connected this is what i see
> >
> > Breakpoint 0’s offset expression evaluation failed.
> > Check for invalid symbols or bad syntax.
> > WaitForEvent failed
> > nt+0x59082:
> > 80537082 8945fc mov [ebp-0x4],eax
> > kd> bl
> > 0 du 0001 (0001) (dummmy!DriverEntry)
> >
> >
> >
> > I have the correct symbols, and path set in the debugger, and this
> > break point is disabled, then why does the kernel panic?
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@stratus.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
you are absolutely right gary. I am using Windbg 6.5
On 8/26/05, Gary G. Little wrote:
> Let me guess … you were unlucky enough to install 6.4 or 6.5? This is the
> same behavior I have seen with versions 6.4 and 6.5. It seems that these
> versions of WinDbg are easily confused about where and how to use symbols,
> even going so far as to have an unrecognizable breakpoint that you cannot
> get around until you provide the proper symbology. Which sometimes you can’t
> because the symbol file you are trying to replace is held by WinDbg causing
> your build to bomb when it creates the PDB file. Doing a “!reload -u” has to
> large a chance on 6.4 and 6.5 of not working so your only alternative is to
> kill WinDbg, build the symbols, and the restart… Even booting the target
> and doing the host build right after the target resets, will not allow the
> PDB file to be built. I have so spent much time trying to get symbols
> usable, that I finally said screw it and fell back to 6.3. I would rather
> debug my code than debug a debugger.
>
> To the WinDbg developers:
>
> I am more than willing to tell you what my target environment is to permit
> you to stage a system that evidences the same problem. I’ll even provide
> dumps and other information I can acquire, within reason, tat may help you
> resolve issues. However, an honest evaluation of what I have seen so far
> with 6.4 and 6.5 is that there was insufficient testing before the release.
> I will provide what info I can, but frankly, debugging the debugger has cost
> me time over the past two weeks that I can ill afford, and unfortunately
> schedules don’t have places in them for faulty WinDbgs. (Sometimes my boss
> thinks I am a wind bag.)
>
> but this thread best belongs in the WinDbg forum.
>
> –
> The personal opinion of
> Gary G. Little
>
> “Bedanto” wrote in message news:xxxxx@ntdev…
> I have a strange problem, my driver runs without a crash normally,
> however when windbg is connected this is what i see
>
> Breakpoint 0’s offset expression evaluation failed.
> Check for invalid symbols or bad syntax.
> WaitForEvent failed
> nt+0x59082:
> 80537082 8945fc mov [ebp-0x4],eax
> kd> bl
> 0 du 0001 (0001) (dummmy!DriverEntry)
>
>
>
> I have the correct symbols, and path set in the debugger, and this
> break point is disabled, then why does the kernel panic?
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Right below the download line for 6.4 on the WinDbg web page.
–
The personal opinion of
Gary G. Little
“Bedanto” wrote in message news:xxxxx@ntdev…
ok, so the debgger is buggy! Well, where can I find winDbg 6.3?
On 8/26/05, Gary G. Little wrote:
> Until 6.4/6.5 it really wasn’t a problem. In 6.3 I find that “!reload -u
> ” is quite effective in releasing the PDB file. In 6.4/6.5 that
> simply does not work reliably. The only reliable did I did find was to
> close
> WinDbg, build and then restart it.6.4/6.5 are simply not worth the time or
> effort to try to use them.
>
> –
> Gary G. Little
>
> “Maxim S. Shatskih” wrote in message
> news:xxxxx@ntdev…
> > I do the same.
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> > ----- Original Message -----
> > From: “Roddy, Mark”
> > To: “Windows System Software Devs Interest List”
> > Sent: Thursday, August 25, 2005 11:14 PM
> > Subject: RE: [ntdev] winDbg causing problems
> >
> >
> > I setup my development builds and my debugger so that the target
> > directory is NOT where I point windbg at to find the symbols for test
> > drivers/exes. That way the worst case is that windbg is looking at the
> > wrong symbols and not that I can’t build because the pdb file is locked.
> > I just have to remember to refresh the test directory as well as the
> > target system. That is error prone of course, but I’ve taken care of
> > that for all but boot drivers by using a map file.
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
> > Sent: Thursday, August 25, 2005 2:33 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re:[ntdev] winDbg causing problems
> >
> > Let me guess … you were unlucky enough to install 6.4 or 6.5? This is
> > the
> > same behavior I have seen with versions 6.4 and 6.5. It seems that these
> >
> > versions of WinDbg are easily confused about where and how to use
> > symbols,
> > even going so far as to have an unrecognizable breakpoint that you
> > cannot
> > get around until you provide the proper symbology. Which sometimes you
> > can’t
> > because the symbol file you are trying to replace is held by WinDbg
> > causing
> > your build to bomb when it creates the PDB file. Doing a “!reload -u”
> > has to
> > large a chance on 6.4 and 6.5 of not working so your only alternative is
> > to
> > kill WinDbg, build the symbols, and the restart… Even booting the
> > target
> > and doing the host build right after the target resets, will not allow
> > the
> > PDB file to be built. I have so spent much time trying to get symbols
> > usable, that I finally said screw it and fell back to 6.3. I would
> > rather
> > debug my code than debug a debugger.
> >
> > To the WinDbg developers:
> >
> > I am more than willing to tell you what my target environment is to
> > permit
> > you to stage a system that evidences the same problem. I’ll even provide
> >
> > dumps and other information I can acquire, within reason, tat may help
> > you
> > resolve issues. However, an honest evaluation of what I have seen so far
> >
> > with 6.4 and 6.5 is that there was insufficient testing before the
> > release.
> > I will provide what info I can, but frankly, debugging the debugger has
> > cost
> > me time over the past two weeks that I can ill afford, and
> > unfortunately
> > schedules don’t have places in them for faulty WinDbgs. (Sometimes my
> > boss
> > thinks I am a wind bag.)
> >
> > but this thread best belongs in the WinDbg forum.
> >
> > –
> > The personal opinion of
> > Gary G. Little
> >
> > “Bedanto” wrote in message news:xxxxx@ntdev…
> > I have a strange problem, my driver runs without a crash normally,
> > however when windbg is connected this is what i see
> >
> > Breakpoint 0’s offset expression evaluation failed.
> > Check for invalid symbols or bad syntax.
> > WaitForEvent failed
> > nt+0x59082:
> > 80537082 8945fc mov [ebp-0x4],eax
> > kd> bl
> > 0 du 0001 (0001) (dummmy!DriverEntry)
> >
> >
> >
> > I have the correct symbols, and path set in the debugger, and this
> > break point is disabled, then why does the kernel panic?
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@stratus.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag argument:
> > ‘’
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>