Hello ,
igyc> In DbgView you can use its filter to filter out
yes I know, but this messages are not from me and only generated from
kernel when dbgview is running.
igyc> unneccessary messages. In WinDbg you can use commands such as
igyc> .ofilter or .outmask
Sorry this is unusable, the messages must filtered out by the source
and not in the windbg sink, than we have a VERY VERY SLOW debug
connection called 1394. I check again for serial debugging than I have
the feeling this has more speed.
Best regards,
elli
As already noted on this list, DebugView fails to support the built-in
features of Windows to limit the traces that it shows. DebugView does
support filtering messages on its own, though, so you could filter
anything starting with “d:\vistartm\base\win32\fusion” to avoid the
below pretty trivially.
.
-----Original Message-----
From: MailingList [mailto:xxxxx@ellisoft.de]
Sent: Wednesday, December 13, 2006 4:47 AM
Subject: windbg + vista rtm unusable
Hello ,
I have a nice session with driver verifier, but using windbg is
impossible. I have running dbgview to see traces and often no work
is possible while windbg flooded my with messages like this
d:\vistartm\base\win32\fusion\inc\fusionhash.h(566): Incremented hash
table 00246474 entries to 1
d:\vistartm\base\win32\fusion\inc\fusionhash.h(544): Successfully
exiting CHashTable
const &,class CGenericStringBuffer<260,class CUnicodeCharTraits>,struct
_ASSEMBLY *,struct _ASSEMBLY *,class
CAssemblyTableHelper,7,0>::CBucketChain::Insert
d:\vistartm\base\win32\fusion\inc\fusionhash.h(206): Successfully
exiting CHashTable
const &,class CGenericStringBuffer<260,class CUnicodeCharTraits>,struct
_ASSEMBLY *,struct _ASSEMBLY *,class CAssemblyTableHelper,7,0>::Insert
d:\vistartm\base\win32\fusion\sxs\actctxgen.cpp(831): Successfully
exiting SxspAddAssemblyToActivationContextGenerationContext
d:\vistartm\base\win32\fusion\sxs\actctxgen.cpp(740): Successfully
exiting SxspAddManifestToActCtxGenCtx
d:\vistartm\base\win32\fusion\id\id.cpp(1499): Entered
SxsDestroyAssemblyIdentity
d:\vistartm\base\win32\fusion\id\id.cpp(1499): Exited
SxsDestroyAssemblyIdentity
d:\vistartm\base\win32\fusion\sxs\actctxgen.cpp(894): Successfully
exiting SxspAddRootManifestToActCtxGenCtx
d:\vistartm\base\win32\fusion\sxs\actctxgen.cpp(1453): Entered
SxspCloseManifestGraph
d:\vistartm\base\win32\fusion\sxs\actctxgen.cpp(1243): Entered
SxspIncorporateAssembly
d:\vistartm\base\win32\fusion\sxs\actctxgen.cpp(981): Entered
SxspIncorporateAssembly
d:\vistartm\base\win32\fusion\id\id.cpp(2499): Entered
SxspGenerateTextualIdentity
d:\vistartm\base\win32\fusion\inc\fusionbuffer.h(566): Entered
CGenericBaseStringBuffer
How can I disable this uninteresting stuff ??? It’s VISTA RTM why such
messages are ebabled ???
Best regards,
elli
I second the approach with the exclusion filter. Also DebugView allows disable all User Mode messages if you don’t want to use the exclusion filter.
Hmm,
lets see:
TARGET:
Runnning checked x86 Vista RTM on Multiprocessor Machine.
Testing with driver verifier a USB-Driver for a device
with isochronous pipes.
Remote Windbg connected via 1394.
Observation: Debug-Messages interfere so much that usb-communication
breaks.
I think: Maybe DbgView can help. So I start dbgView on the
checked build. It does not start directly, I have to use
windbg on the target to start it (“windbg dbgview.exe”).
This locks up because dbgView has some user-mode errors
when it comes to programming the list-view.
- Flood of comctlv6-messages : “RIP …”
- Clicking inside the listview gives an exception.
RESULT: I have no solution for my target environment.
Does the command ‘ofilter’ filter the messages on the target or only
in the remote host ?
What are the built-in features of Windows to limit the traces ?
Norbert.
---- snip ----
As already noted on this list, DebugView fails to support the built-in
features of Windows to limit the traces that it shows. DebugView does
support filtering messages on its own, though, so you could filter
anything starting with “d:\vistartm\base\win32\fusion” to avoid the
below pretty trivially.
---- snip ----
You can manipulate DbgPrint/KdPrint and DbgPrintEx/KdPrintEx on the target using either registry or WinDbg. Please refer to the “Reading and Filtering Debugging Messages” article in the WinDbg’s Help for that matter.
Henry Gabryjelski wrote:
As already noted on this list, DebugView fails to support the built-in
features of Windows to limit the traces that it shows. DebugView does
support filtering messages on its own, though, so you could filter
anything starting with “d:\vistartm\base\win32\fusion” to avoid the
below pretty trivially.
Does this note mean that Vista unconditionally generates boatloads of
debug traces, and it is only filtering in the kernel debugger that
prevents those boatloads from flooding the windbg output? Is the
filtering taking place in the target, or in the host?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
We’re filtering on the system side not on the debugger side.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, December 18, 2006 3:49 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] windbg + vista rtm unusable
Henry Gabryjelski wrote:
As already noted on this list, DebugView fails to support the built-in
features of Windows to limit the traces that it shows. DebugView does
support filtering messages on its own, though, so you could filter
anything starting with “d:\vistartm\base\win32\fusion” to avoid the
below pretty trivially.
Does this note mean that Vista unconditionally generates boatloads of
debug traces, and it is only filtering in the kernel debugger that
prevents those boatloads from flooding the windbg output? Is the
filtering taking place in the target, or in the host?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Peter Wieland wrote:
We’re filtering on the system side not on the debugger side.
Yes, I actually found this written in the documentation after I sent my
question.
However, that does lead to a 10-point followup question: Why does
DebugView see all of the unfiltered messages? Is DebugView hooking the
API at too high of a level?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.