(resending to correct list (funny how sending posts to 'request'
doesn't work...*doi!*)....
I have upgraded to latest 1.6.0
Can't get it not to crash when monitoring my internal GB net (with no
filters on).
If I turn on filters to exclude all SMB traffic, OR if I monitor my 2nd
interface that gets
little traffic...it works fine...but
when monitoring a full speed dump....crashes so fast....it's not funny!
I've tried setting up ring buffered capture files 4GB each, ringsize=8,
(no go).
Single file was nogo.
No capture file was 'nogo' (but that goes to page? I only have 24G
phys and about 48G of page file on top of that). It's a 6-core
machine, with 3.33GHz Xeon, so it's no slouch, but it
is running Win7-64.
It is almost always the case that I can't stop a trace before it
crashes....a debug window comes up with some error or another.
This time saw several messages all in a row, that said:
------------------
18:57:39 Warn Too many taps queued
18:57:39 Warn Too many taps queued
18:57:39 Warn Too many taps queued
18:57:39 Warn Too many taps queued
18:57:39 Warn Too many taps queued
18:57:39 Warn Too many taps queued
18:57:39 Warn Too many taps queued
18:57:39 Warn Too many taps queued
18:57:39 Warn Too many taps queued
18:57:39 Warn Too many taps queued
18:57:39 Warn Too many taps queued
---
Then an error popup from:
[Microsoft Visual C++ Runtime Library]
The application has request the Runtime to terminate it in an
unusual way.
Please contact the application's support team for more information.
-----
I've had this problem for a while, but worked around it with
filters....but I want to be able to trace loaded SMB2 traffic
that's is being read from the server at up to 112-115MB/s,
though 80-90MB/s is more typical...
Ideas?
