Hi Mike,
Post by Michael AcostaHi Yang,
Thank you for the reply.
I suppose we could try to jump through hoops to disassemble and
otherwise hack around and try to figure out what is happening here,
but it would be a lot more helpful if the PDB were available from the
build that we and some of our customers actually have installed. It's
an open-source package, so I'm not understanding the reluctance of the
build maintainers to package or make available the actual debug
symbols - we're not going to find any secrets that the code doesn't
already tell us.
Except various Windows releases, I never see another software could keep
its symbols public as well as its package, especially for a open-source
software, it just assumes that you are capable to build it from source and
do anything you want. Maybe you could still resort to WinPcap's original
author, if lucky, maybe he still keeps the original PDB files. BTW, as what
you used is WinPcap's release version, I think you want to be provided with
release symbols instead of debug symbols, in order to make the PDB match
the binary.
Post by Michael AcostaSince this is a rare bug, it's taken a long time to get a memory dump
from a system in-situ; most of the time it is not feasible to have a
customer take an extended outage to gather the information. Luckily,
we caught this one in-house. This is something I would hope Riverbed
would like to solve, as I've seen in the past similar issues reported
AFAIK, Wireshark (sponsored by Riverbed) has taken control of the WinPcap
dev work. I'm not sure if Riverbed would directly dedicate to WinPcap's
troubleshooting.
Post by Michael Acostawith Wireshark due to NPF.sys. The workaround seems to be to set the
driver to start on demand rather than on boot, but nobody seems to
have a handle on the cause.
By the way, I'm excited about your npcap project. I plan on testing
with this to see if it's a replacement for WinPCAP 4.1.3 that is more
stable in the ways we use it. In the future, do you plan on making the
full build available, including symbols, on release?
Npcap is supported on Win7 (2008 R2) and later systems, so I think it
adapts to your scenario. You can try it on your environment and I would
like to fix any bugs if possible if you encountered any. The latest version
Npcap is 0.05:
https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/npcap-nmap-0.05.exe
And, it's not hard to include the symbols, they are just lying on my hard
disk right now, if you like, I can provide them together with the binaries
on my SVN repo:)
Cheers,
Yang
Post by Michael AcostaThank you again,
-- Mike
Post by é£è大ç°å
V5Hi Michael,
A seemingly viable way would be that you decompile your driver (npf.sys)
into C code using IDA pro, cross-searched the failing address in IDA and
WinPcap souce code, you will probably find the wrong line of code.
Cheers,
Yang
Post by Michael AcostaHi,
We've been using WinPCAP optionally to send GARP frames on Windows
server (2008r2 and up), but it sometimes seems to hang in a call. It's
not easily reproducible, but I managed to get a kernel memory dump
today of the issue - the problem is that we do not have the symbols
for 4.1.3 to see what it's doing in WINDBG.
Can someone provide the symbols to me so we can see what's hanging up
here? If we compile on our own, the PDB isn't going to match our
running environment, and since it's not easily reproducable we're kind
of light on collected kernel data, so just building our own is not an
option at this point. We need to see the symbols from the version
built and accessible on winpcap.org in order to make progress here.
Please let me know if you need more information.
Thank you,
--
Michael Acosta
_______________________________________________
Winpcap-users mailing list
https://www.winpcap.org/mailman/listinfo/winpcap-users
_______________________________________________
Winpcap-users mailing list
https://www.winpcap.org/mailman/listinfo/winpcap-users
--
Michael Acosta
_______________________________________________
Winpcap-users mailing list
https://www.winpcap.org/mailman/listinfo/winpcap-users