RE: ETW and debug prints

Yes I saw this question before and have wondered about what to say. I
don’t know these products so I don’t know of what they are capable.

One of the main objectives of WPP style tracing is to be on in retail
bits so the main idea is to keep the overhead low. So the data is packed
and we prefil a lot of decode and extra info (format statement, line
number etc.) into the decode files (PDB or TMF). We deliberately didn’t
do the synchronous operation of a debug print because we wanted to
impact timing as little as possible. One of our goals has been to try to
make it possible to debug some timing bugs which are notoriously
difficult with debuggers.

So the processing has to recognize this is a trace message and invoke
the Traceprt DLL which does the munging together. That’s what tracefmt
and and traceview do, we added this capability as a convenience in some
debug situations where we could do it easily.

While I am sure it is not really satisfactory you can define the macro

#define WPP_DEBUG(a) printf a , printf(“\n”)

(use your favorite debug print)
And WPP will generate the statements for you AS WELL as the trace
statements. But note you do not get any of the timing or code size
advantages and you cannot use any of the WPP fancy formatting. I don’t
really recommend this but maybe it is helpful in debug only code.

Just while we are here the other useful macro
#define WppDebug(a,b) printf b ;
(Again choose the debug statement u like)
Will display significant WPP internal operations such as flags set and
cleared. This is usually helpful when things are not turning on or off
as you expect.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Monday, February 16, 2004 12:20 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Moron ETW


From:
xxxxx@windows.microsoft.com[SMTP:xxxxx@windows.microsoft.com]
Reply To: xxxxx@lists.osr.com
Sent: Monday, February 16, 2004 8:47 PM
To: xxxxx@lists.osr.com
Subject: RE: [ntdev] Moron ETW

If you guys can post some of the specific questions I will try and get
them answered for you in as timely a fashion as possible.

Most you seem to have resolved yourselves, but let me know what is
outstanding?

If you could look into previous discussion, there were a lot unanswerred
questions.

The one which is the most important for me: is there a way how to
redirect
ETW traces to debug output in real time? I’m not interested how to do it
with windbg because prefer SoftICE or DbgView. By real time I mean trace
is
formatted and printed out before original call in the driver returns.
Note
conditions compilation isn’t an acceptable solution because binaries
differ
and I want to use the same binary for both development and testing.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.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@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Ian,

thanks, you finally answered it. Several notes and questions below.


From:
xxxxx@windows.microsoft.com[SMTP:xxxxx@windows.microsoft.com]
Reply To: xxxxx@lists.osr.com
Sent: Monday, February 16, 2004 10:15 PM
To: xxxxx@lists.osr.com
Subject: RE: [ntdev] ETW and debug prints

Yes I saw this question before and have wondered about what to say. I
don’t know these products so I don’t know of what they are capable.

Sorry, I presumed it is obvious. They capture kernel DbgPrint and user mode
OutputDebugPrint and display them.

One of the main objectives of WPP style tracing is to be on in retail
bits so the main idea is to keep the overhead low. So the data is packed
and we prefil a lot of decode and extra info (format statement, line
number etc.) into the decode files (PDB or TMF). We deliberately didn’t
do the synchronous operation of a debug print because we wanted to
impact timing as little as possible. One of our goals has been to try to
make it possible to debug some timing bugs which are notoriously
difficult with debuggers.

Which can be very helpful and one of strongs reasons to use it. I only
wondered if there isn’t an option for synchronous output.

Well, if synchronous output isn’t possible, what if there are traces from
several sources at once? Is their order preserved? For example if an app
makes trace #1, calls a driver which makes trace #2, returns and app then
makes trace #3, is it ensured traces appear in #1, #2, #3 order?

BTW, is it possible to extract traces from crashdump? The most interesting
traces which occurs just before crash usually aren’t flushed. I’m asking
because DbgView allows it (it simply finds its buffer in crashdump) and with
some effort it is also possible to find SoftICE history buffer which
contains and debug prints. I found it very helpful in several cases.

So the processing has to recognize this is a trace message and invoke
the Traceprt DLL which does the munging together. That’s what tracefmt
and and traceview do, we added this capability as a convenience in some
debug situations where we could do it easily.

I guess it would be possible to write an app or a service which would format
traces and send them to debug output. It would be probably suffcient in most
situations if trace order is preserved.

While I am sure it is not really satisfactory you can define the macro

#define WPP_DEBUG(a) printf a , printf(“\n”)

(use your favorite debug print)
And WPP will generate the statements for you AS WELL as the trace
statements. But note you do not get any of the timing or code size
advantages and you cannot use any of the WPP fancy formatting. I don’t
really recommend this but maybe it is helpful in debug only code.

Interesting. Previously I haven’t noticed “as well” part. Just to be sure –
does it mean ETW checks flag and level and only if decides trace should be
logged, it calls both trace call and debug print?

Just while we are here the other useful macro
#define WppDebug(a,b) printf b ;
(Again choose the debug statement u like)
Will display significant WPP internal operations such as flags set and
cleared. This is usually helpful when things are not turning on or off
as you expect.

Thanks, it is good to know about it.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

>Sorry, I presumed it is obvious. They capture kernel DbgPrint and user
mode

OutputDebugPrint and display them.
Well OK I do know the obvious :-), but I don’t know if there is
anywhere they could call for example Traceprt.

Which can be very helpful and one of strong reasons to use it. I only
wondered if there isn’t an option for synchronous output
Unfortunately there is not currently.

Well, if synchronous output isn’t possible, what if there are traces
from
several sources at once?
Well what does the order being preserved mean when we are not
synchronous? The answer is as much as we possibly can be, we use the
Event Tracing for Windows (ETW) calls to do the logging and as you will
have seen we have various options such as using the fine grained clocks
and sequence numbers to try to make this as meaningful as possible, But
these events may just actually be happening at the same time; in fact
that may well be the problem you are looking for.

BTW, is it possible to extract traces from crashdump?
Yes, the WmiTrace KD extension can dump traces from a crash

I guess it would be possible to write an app or a service which would
format traces and send them to debug output…
I played with that once and you can use the -ods option to
tracefmt to do this, but as its not in sync with the real debug prints I
think you don’t help yourself as much as you would want. You may in fact
confuse the issue.

nteresting. Previously I haven’t noticed “as well” part. Just to be
sure –
does it mean ETW checks flag and level and only if decides trace should
be
logged, it calls both trace call and debug print?
Yes that’s correct. We check the flags before we make the calls

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Monday, February 16, 2004 2:00 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW and debug prints

Ian,

thanks, you finally answered it. Several notes and questions below.


From:
xxxxx@windows.microsoft.com[SMTP:xxxxx@windows.microsoft.com]
Reply To: xxxxx@lists.osr.com
Sent: Monday, February 16, 2004 10:15 PM
To: xxxxx@lists.osr.com
Subject: RE: [ntdev] ETW and debug prints

Yes I saw this question before and have wondered about what to say. I
don’t know these products so I don’t know of what they are capable.

Sorry, I presumed it is obvious. They capture kernel DbgPrint and user
mode
OutputDebugPrint and display them.

One of the main objectives of WPP style tracing is to be on in retail
bits so the main idea is to keep the overhead low. So the data is
packed
and we prefil a lot of decode and extra info (format statement, line
number etc.) into the decode files (PDB or TMF). We deliberately
didn’t
do the synchronous operation of a debug print because we wanted to
impact timing as little as possible. One of our goals has been to try
to
make it possible to debug some timing bugs which are notoriously
difficult with debuggers.

Which can be very helpful and one of strongs reasons to use it. I only
wondered if there isn’t an option for synchronous output.

Well, if synchronous output isn’t possible, what if there are traces
from
several sources at once? Is their order preserved? For example if an app
makes trace #1, calls a driver which makes trace #2, returns and app
then
makes trace #3, is it ensured traces appear in #1, #2, #3 order?

BTW, is it possible to extract traces from crashdump? The most
interesting
traces which occurs just before crash usually aren’t flushed. I’m asking
because DbgView allows it (it simply finds its buffer in crashdump) and
with
some effort it is also possible to find SoftICE history buffer which
contains and debug prints. I found it very helpful in several cases.

So the processing has to recognize this is a trace message and invoke
the Traceprt DLL which does the munging together. That’s what tracefmt
and and traceview do, we added this capability as a convenience in
some
debug situations where we could do it easily.

I guess it would be possible to write an app or a service which would
format
traces and send them to debug output. It would be probably suffcient in
most
situations if trace order is preserved.

While I am sure it is not really satisfactory you can define the macro

#define WPP_DEBUG(a) printf a , printf(“\n”)

(use your favorite debug print)
And WPP will generate the statements for you AS WELL as the trace
statements. But note you do not get any of the timing or code size
advantages and you cannot use any of the WPP fancy formatting. I don’t
really recommend this but maybe it is helpful in debug only code.

Interesting. Previously I haven’t noticed “as well” part. Just to be
sure –
does it mean ETW checks flag and level and only if decides trace should
be
logged, it calls both trace call and debug print?

Just while we are here the other useful macro
#define WppDebug(a,b) printf b ;
(Again choose the debug statement u like)
Will display significant WPP internal operations such as flags set and
cleared. This is usually helpful when things are not turning on or off
as you expect.

Thanks, it is good to know about it.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.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@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

> ----------

From:
xxxxx@windows.microsoft.com[SMTP:xxxxx@windows.microsoft.com]
Reply To: xxxxx@lists.osr.com
Sent: Monday, February 16, 2004 11:32 PM
To: xxxxx@lists.osr.com
Subject: RE: [ntdev] ETW and debug prints

>Sorry, I presumed it is obvious. They capture kernel DbgPrint and user
mode
>OutputDebugPrint and display them.
Well OK I do know the obvious :-), but I don’t know if there is
anywhere they could call for example Traceprt.

Ah so. Probably not; SoftICE can call a KD extension but I guess it isn’t
sufficient.

Thanks for answers, it seems I’ll have to try it to see more. The last
question: currently we’re using debug areas and every area has assigned
debug level (as trace, warning, error). One application/driver usually uses
several areas. ETW seems to use bit flags and one level which is global for
all. How to map our approach to it? I see two possibilities – use one GUID
per area and use level only or reserve 3 bits/flags per area and express
level as value of these bits. I’m not sure if the second is even possible
with ETW macros. Any other possibility? And are there any non-obvious
consequences?

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

>currently we’re using debug areas and every area has assigned

debug level (as trace, warning, error). One application/driver usually
uses
several areas.

Well one thing we tried to do was to be a flexible as possible here to
incorporate multiple different models. However we tend to steer new
implementations towards the levels model because of its
straightforwardness.

It is also convenient to have a common concept so that support
organizations can straightforwardly turn on tracing for mixed components
together.

However sometimes that’s not what is wanted.

I think the most common thing that is done is to define flags and levels
together and adjust the macros appropriately.This is the sort of example
that Mark was trying to achieve at the start of this discussion. You can
override the macros to have there own meaning of what LEVEL and FLAGS
really are in your case.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Monday, February 16, 2004 3:08 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW and debug prints


From:
xxxxx@windows.microsoft.com[SMTP:xxxxx@windows.microsoft.com]
Reply To: xxxxx@lists.osr.com
Sent: Monday, February 16, 2004 11:32 PM
To: xxxxx@lists.osr.com
Subject: RE: [ntdev] ETW and debug prints

>Sorry, I presumed it is obvious. They capture kernel DbgPrint and
user
mode
>OutputDebugPrint and display them.
Well OK I do know the obvious :-), but I don’t know if there is
anywhere they could call for example Traceprt.

Ah so. Probably not; SoftICE can call a KD extension but I guess it
isn’t
sufficient.

Thanks for answers, it seems I’ll have to try it to see more. The last
question: currently we’re using debug areas and every area has assigned
debug level (as trace, warning, error). One application/driver usually
uses
several areas. ETW seems to use bit flags and one level which is global
for
all. How to map our approach to it? I see two possibilities – use one
GUID
per area and use level only or reserve 3 bits/flags per area and express
level as value of these bits. I’m not sure if the second is even
possible
with ETW macros. Any other possibility? And are there any non-obvious
consequences?

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.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@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

For instance I modified the example henry provided so that I have an ‘always
log’ level independent of the flags that are set:

#define WPP_LEVEL_FLAGS_ENABLED(lvl, flags) \
(WPP_CONTROL(WPP_BIT_ ## flags).Level == GENSHELL_DEBUG_ALWAYS) || \
((WPP_LEVEL_ENABLED(flags) && \
(WPP_CONTROL(WPP_BIT_ ## flags).Level >= lvl)))

This compiles (at the moment I have no idea if it works,) but the mechanism
appears to be fairly straight-forward (although undocumented of course) and
flexible enough to accommodate more complex schemes. There is probably some
way to work your level-per-component scheme into this.

Now my problem is that I can control the trace flags from the traceview
application, but I have to set the levels from my own interface. That bites
from a usability perspective, but unless I am missing yet another
undocumented feature (which would of course be just about all of the ETW
features) I think I am stuck with this.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ian Service
Sent: Monday, February 16, 2004 6:21 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW and debug prints

>currently we’re using debug areas and every area has assigned debug
>level (as trace, warning, error). One application/driver usually
uses
>several areas.

Well one thing we tried to do was to be a flexible as
possible here to incorporate multiple different models.
However we tend to steer new implementations towards the
levels model because of its straightforwardness.

It is also convenient to have a common concept so that
support organizations can straightforwardly turn on tracing
for mixed components together.

However sometimes that’s not what is wanted.

I think the most common thing that is done is to define flags
and levels together and adjust the macros appropriately.This
is the sort of example that Mark was trying to achieve at the
start of this discussion. You can override the macros to have
there own meaning of what LEVEL and FLAGS really are in your case.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Monday, February 16, 2004 3:08 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW and debug prints

> ----------
> From:
> xxxxx@windows.microsoft.com[SMTP:xxxxx@windows.microsoft.com]
> Reply To: xxxxx@lists.osr.com
> Sent: Monday, February 16, 2004 11:32 PM
> To: xxxxx@lists.osr.com
> Subject: RE: [ntdev] ETW and debug prints
>
> >Sorry, I presumed it is obvious. They capture kernel DbgPrint and
user
> mode
> >OutputDebugPrint and display them.
> Well OK I do know the obvious :-), but I don’t know if there is
> anywhere they could call for example Traceprt.
>
Ah so. Probably not; SoftICE can call a KD extension but I
guess it isn’t sufficient.

Thanks for answers, it seems I’ll have to try it to see more. The last
question: currently we’re using debug areas and every area
has assigned debug level (as trace, warning, error). One
application/driver usually uses several areas. ETW seems to
use bit flags and one level which is global for all. How to
map our approach to it? I see two possibilities – use one
GUID per area and use level only or reserve 3 bits/flags per
area and express level as value of these bits. I’m not sure
if the second is even possible with ETW macros. Any other
possibility? And are there any non-obvious consequences?

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.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@windows.microsoft.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:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com

Here is some code I use to enable and disable logging from my application.
It has been sanitized so I may not compile, let me know if you have
trouble…

#define MAX_STRLEN 255
#define MAX_SESSIONS 32
#define MY_EVENT_TRACING_SESSION_NAME L"MyDriver"
#define MY_EVENT_TRACING_LOGFILE_NAME L"MyDriver.etl"

typedef ULONG (*tStartTrace)(
OUT PTRACEHANDLE TraceHandle,
IN LPCWSTR InstanceName,
IN OUT PEVENT_TRACE_PROPERTIES Properties
);

typedef ULONG (*tStopTrace)(
IN TRACEHANDLE TraceHandle,
IN LPCWSTR InstanceName,
IN OUT PEVENT_TRACE_PROPERTIES Properties
);
typedef ULONG (*tQueryTrace)(
IN TRACEHANDLE TraceHandle,
IN LPCWSTR InstanceName,
IN OUT PEVENT_TRACE_PROPERTIES Properties
);

typedef ULONG (*tControlTrace)(
IN TRACEHANDLE TraceHandle,
IN LPCWSTR InstanceName,
IN OUT PEVENT_TRACE_PROPERTIES Properties,
IN ULONG ControlCode
);

typedef ULONG (*tEnableTrace)(
IN ULONG Enable,
IN ULONG EnableFlag,
IN ULONG EnableLevel,
IN LPCGUID ControlGuid,
IN TRACEHANDLE TraceHandle
);

typedef ULONG (*tQueryAllTraces)(
OUT PEVENT_TRACE_PROPERTIES *PropertyArray,
IN ULONG PropertyArrayCount,
OUT PULONG LoggerCount
);

tStartTrace pStartTrace=NULL;
tStopTrace pStopTrace=NULL;
tQueryTrace pQueryTrace=NULL;
tControlTrace pControlTrace=NULL;
tEnableTrace pEnableTrace=NULL;
tQueryAllTraces pQueryAllTraces=NULL;

BOOLEAN DoImports( void )
{
if(!pStartTrace) {
pStartTrace =
(tStartTrace)GetProcAddress(GetModuleHandle(TEXT(“advapi32”)),“StartTraceW”)
;
pStopTrace =
(tStopTrace)GetProcAddress(GetModuleHandle(TEXT(“advapi32”)),“StopTraceW”);
pQueryTrace =
(tQueryTrace)GetProcAddress(GetModuleHandle(TEXT(“advapi32”)),“QueryTraceW”)
;
pControlTrace =
(tControlTrace)GetProcAddress(GetModuleHandle(TEXT(“advapi32”)),“ControlTrac
eW”);
pEnableTrace =
(tEnableTrace)GetProcAddress(GetModuleHandle(TEXT(“advapi32”)),“EnableTrace”
);
pQueryAllTraces =
(tQueryAllTraces)GetProcAddress(GetModuleHandle(TEXT(“advapi32”)),“QueryAllT
racesW”);

if(pStartTrace) {
return TRUE;
}

return FALSE;
} else {
return TRUE;
}
}

ULONG GetRegistryDword_global (
const WCHAR * ValueName,
ULONG DefaultValue )
{
ULONG Err=0;
HKEY Key = INVALID_HANDLE_VALUE;
const WCHAR *RegPath =
L"SYSTEM\CurrentControlSet\Services\MyDriver\";
ULONG Value = DefaultValue;

Err = RegOpenKeyExW (
HKEY_LOCAL_MACHINE,
RegPath,
0,
KEY_READ,
&Key );

if ( Err == 0 ) {
ULONG TempValue = 0;
ULONG DataSize = sizeof(TempValue);
Err = RegQueryValueExW (
Key,
ValueName,
NULL, // reserved
NULL, // address of buffer for value type
(char*)(&TempValue),
&DataSize );

if ( Err == 0 ) {
Value = TempValue;
}

RegCloseKey(Key);
Key = INVALID_HANDLE_VALUE;
} else {
DEBUG_WRITE(L">>> GetRegistryDword: error %08x opening
‘%s’\n",RegPath);
}

return Value;
}

PEVENT_TRACE_PROPERTIES AllocSessionProperties()
{
PEVENT_TRACE_PROPERTIES Properties;
ULONG SizeNeeded;

// Calculate the size needed to store the properties,
// a LogFileName string, and LoggerName string.

SizeNeeded = sizeof(EVENT_TRACE_PROPERTIES) +
(2 * MAX_STRLEN * sizeof(WCHAR));
Properties = (PEVENT_TRACE_PROPERTIES) malloc(SizeNeeded);

if ( Properties == NULL ) {
SetLastError(ERROR_OUTOFMEMORY);
return NULL;
}

ZeroMemory( Properties, SizeNeeded );

// Set the location for the event tracing session name.
// LoggerNameOffset is a relative address.
Properties->LoggerNameOffset = sizeof(EVENT_TRACE_PROPERTIES);

// Set the log file name location.
// LogFileNameOffset is a relative address.
Properties->LogFileNameOffset = sizeof(EVENT_TRACE_PROPERTIES) +
(MAX_STRLEN * sizeof(WCHAR));

// Store the total number of bytes pointed to by Properties.
Properties->Wnode.BufferSize = SizeNeeded;

// The WNODE_HEADER is being used.
Properties->Wnode.Flags = WNODE_FLAG_TRACED_GUID;

RtlCopyMemory(&Properties->Wnode.Guid,&MY_DRIVER_WPP_GUID,sizeof(GUID));

DEBUG_WRITE(L"Size = %d\n",SizeNeeded);
return Properties;
}

ULONG EnableProvider(TRACEHANDLE SessionHandle)
{
if(DoImports()) {
ULONG ret;
ULONG DebugLevel =
GetRegistryDword_global(L"DebugLevel",0x0fffffff);

ret = pEnableTrace (
(ULONG)TRUE, // True = enable; FALSE = disable.
DebugLevel, // Flag.
0, // Level.
&MY_DRIVER_WPP_GUID, // Provider to enable.
SessionHandle); // Identifies the session.
wprintf(L"enable = %08x\n",ret);
return ret;
} else {
return 0xffffffff;
}
}

ULONG DisableProvider(TRACEHANDLE SessionHandle)
{
if(DoImports()) {
ULONG ret;

ret = pEnableTrace (
(ULONG)FALSE,//True = enable; FALSE = disable.
0, // Flag.
0, // Level.
&MY_DRIVER_WPP_GUID, // Provider to enable.
SessionHandle); // Identifies the session.
return ret;
} else {
return 0xffffffff;
}
}

ULONG StopMySession(TRACEHANDLE MyHandle)
{
if(DoImports()) {
ULONG ret;
PEVENT_TRACE_PROPERTIES Properties;

Properties = AllocSessionProperties();
if ( Properties == NULL ) {
return(ERROR_OUTOFMEMORY);
}
if(MyHandle == (TRACEHANDLE)INVALID_HANDLE_VALUE) {
DEBUG_WRITE(L"Stopping via session name\n");
ret = pControlTrace (MyHandle, MY_EVENT_TRACING_SESSION_NAME,
Properties, EVENT_TRACE_CONTROL_STOP);
} else {
DEBUG_WRITE(L"Stopping via session properties\n");
ret = pControlTrace (MyHandle, NULL, Properties,
EVENT_TRACE_CONTROL_STOP);
}
if ( ret == ERROR_SUCCESS ) {
wprintf(L"\n\n Stopped…\n");
PrintSession(Properties);
} else {
wprintf(L"\nError %08x stopping\n",ret);
}
free(Properties);
return ret;
} else {
return 0xffffffff;
}
}

TRACEHANDLE StartMySession()
{
if(DoImports()) {
ULONG ret;
PEVENT_TRACE_PROPERTIES Properties;
TRACEHANDLE SessionHandle=(TRACEHANDLE)INVALID_HANDLE_VALUE;

Properties = AllocSessionProperties();
if ( Properties == NULL ) {
return((TRACEHANDLE) INVALID_HANDLE_VALUE);
}

if(GetRegistryDword_global(L"DebugLogCircular",1)) {
// Deliver events to a circular log file.
Properties->LogFileMode |= EVENT_TRACE_FILE_MODE_CIRCULAR ;
}

// Circular log files should have a maximum size.
Properties->MaximumFileSize =
GetRegistryDword_global(L"DebugLogMaxSize",20);

// with just the file name it will store it in the current
directory.
//wcscpy(EventTracingFile,MY_EVENT_TRACING_LOGFILE_NAME);

GetSSPath(EventTracingFile,sizeof(EventTracingFile)/sizeof(WCHAR));
wcscat(EventTracingFile,MY_EVENT_TRACING_LOGFILE_NAME);

// Store the name of the log file.
wcscpy ((LPWSTR) ((char *)Properties +
Properties->LogFileNameOffset), EventTracingFile);

// Choose some buffer settings.
Properties->BufferSize =
GetRegistryDword_global(L"DebugLogBufferSize",4);
Properties->MinimumBuffers =
GetRegistryDword_global(L"DebugLogMinBuffers",3);
Properties->MaximumBuffers =
GetRegistryDword_global(L"DebugLogMaxBuffers",6);

// Start the session.
ret = pStartTrace (&SessionHandle,
MY_EVENT_TRACING_SESSION_NAME,
Properties);

if ( ret!= ERROR_SUCCESS ) {
wprintf(L"StartTrace failed: %d\n", ret);
PrintWin32Error(ret);
PrintSession(Properties);
SessionHandle = (TRACEHANDLE) INVALID_HANDLE_VALUE;
} else {
PrintSession(Properties);
EnableProvider(SessionHandle);
//QueryAll();
}
free(Properties);
return SessionHandle;
} else {
return (TRACEHANDLE)NULL;
}
}

Thanks,
Rob

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-167589-
xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, February 16, 2004 7:14 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW and debug prints

For instance I modified the example henry provided so that I have an
‘always
log’ level independent of the flags that are set:

#define WPP_LEVEL_FLAGS_ENABLED(lvl, flags) \
(WPP_CONTROL(WPP_BIT_ ## flags).Level == GENSHELL_DEBUG_ALWAYS) || \
((WPP_LEVEL_ENABLED(flags) && \
(WPP_CONTROL(WPP_BIT_ ## flags).Level >= lvl)))

This compiles (at the moment I have no idea if it works,) but the
mechanism
appears to be fairly straight-forward (although undocumented of course)
and
flexible enough to accommodate more complex schemes. There is probably
some
way to work your level-per-component scheme into this.

Now my problem is that I can control the trace flags from the traceview
application, but I have to set the levels from my own interface. That
bites
from a usability perspective, but unless I am missing yet another
undocumented feature (which would of course be just about all of the ETW
features) I think I am stuck with this.

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Ian Service
> Sent: Monday, February 16, 2004 6:21 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] ETW and debug prints
>
>
>
> >currently we’re using debug areas and every area has assigned debug
> >level (as trace, warning, error). One application/driver usually
> uses
> >several areas.
>
> Well one thing we tried to do was to be a flexible as
> possible here to incorporate multiple different models.
> However we tend to steer new implementations towards the
> levels model because of its straightforwardness.
>
> It is also convenient to have a common concept so that
> support organizations can straightforwardly turn on tracing
> for mixed components together.
>
> However sometimes that’s not what is wanted.
>
> I think the most common thing that is done is to define flags
> and levels together and adjust the macros appropriately.This
> is the sort of example that Mark was trying to achieve at the
> start of this discussion. You can override the macros to have
> there own meaning of what LEVEL and FLAGS really are in your case.
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
> Sent: Monday, February 16, 2004 3:08 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] ETW and debug prints
>
> > ----------
> > From:
> > xxxxx@windows.microsoft.com[SMTP:xxxxx@windows.microsoft.com]
> > Reply To: xxxxx@lists.osr.com
> > Sent: Monday, February 16, 2004 11:32 PM
> > To: xxxxx@lists.osr.com
> > Subject: RE: [ntdev] ETW and debug prints
> >
> > >Sorry, I presumed it is obvious. They capture kernel DbgPrint and
> user
> > mode
> > >OutputDebugPrint and display them.
> > Well OK I do know the obvious :-), but I don’t know if there is
> > anywhere they could call for example Traceprt.
> >
> Ah so. Probably not; SoftICE can call a KD extension but I
> guess it isn’t sufficient.
>
> Thanks for answers, it seems I’ll have to try it to see more. The last
> question: currently we’re using debug areas and every area
> has assigned debug level (as trace, warning, error). One
> application/driver usually uses several areas. ETW seems to
> use bit flags and one level which is global for all. How to
> map our approach to it? I see two possibilities – use one
> GUID per area and use level only or reserve 3 bits/flags per
> area and express level as value of these bits. I’m not sure
> if the second is even possible with ETW macros. Any other
> possibility? And are there any non-obvious consequences?
>
> Best regards,
>
> Michal Vodicka
> STMicroelectronics Design and Application s.r.o.
> [michal.vodicka@st.com, http:://www.st.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@windows.microsoft.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:
> xxxxx@hollistech.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: xxxxx@cdp.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

That macro modification is variant of one that I have seen before and
should work. One very simple model that gives you a flags worth of
components is a bit per component plus use levels for the depth of
tracing.

Can you not set the levels from the Advanced Log Session options?

Note you can also use tracelog and/or logman to start/stop sessions
and set levels and flags if you need some other capabilities.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Monday, February 16, 2004 4:14 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW and debug prints

For instance I modified the example henry provided so that I have an
‘always
log’ level independent of the flags that are set:

#define WPP_LEVEL_FLAGS_ENABLED(lvl, flags) \
(WPP_CONTROL(WPP_BIT_ ## flags).Level == GENSHELL_DEBUG_ALWAYS) || \
((WPP_LEVEL_ENABLED(flags) && \
(WPP_CONTROL(WPP_BIT_ ## flags).Level >= lvl)))

This compiles (at the moment I have no idea if it works,) but the
mechanism
appears to be fairly straight-forward (although undocumented of course)
and
flexible enough to accommodate more complex schemes. There is probably
some
way to work your level-per-component scheme into this.

Now my problem is that I can control the trace flags from the traceview
application, but I have to set the levels from my own interface. That
bites
from a usability perspective, but unless I am missing yet another
undocumented feature (which would of course be just about all of the ETW
features) I think I am stuck with this.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ian Service
Sent: Monday, February 16, 2004 6:21 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW and debug prints

>currently we’re using debug areas and every area has assigned debug
>level (as trace, warning, error). One application/driver usually
uses
>several areas.

Well one thing we tried to do was to be a flexible as
possible here to incorporate multiple different models.
However we tend to steer new implementations towards the
levels model because of its straightforwardness.

It is also convenient to have a common concept so that
support organizations can straightforwardly turn on tracing
for mixed components together.

However sometimes that’s not what is wanted.

I think the most common thing that is done is to define flags
and levels together and adjust the macros appropriately.This
is the sort of example that Mark was trying to achieve at the
start of this discussion. You can override the macros to have
there own meaning of what LEVEL and FLAGS really are in your case.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Monday, February 16, 2004 3:08 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW and debug prints

> ----------
> From:
> xxxxx@windows.microsoft.com[SMTP:xxxxx@windows.microsoft.com]
> Reply To: xxxxx@lists.osr.com
> Sent: Monday, February 16, 2004 11:32 PM
> To: xxxxx@lists.osr.com
> Subject: RE: [ntdev] ETW and debug prints
>
> >Sorry, I presumed it is obvious. They capture kernel DbgPrint and
user
> mode
> >OutputDebugPrint and display them.
> Well OK I do know the obvious :-), but I don’t know if there is
> anywhere they could call for example Traceprt.
>
Ah so. Probably not; SoftICE can call a KD extension but I
guess it isn’t sufficient.

Thanks for answers, it seems I’ll have to try it to see more. The last
question: currently we’re using debug areas and every area
has assigned debug level (as trace, warning, error). One
application/driver usually uses several areas. ETW seems to
use bit flags and one level which is global for all. How to
map our approach to it? I see two possibilities – use one
GUID per area and use level only or reserve 3 bits/flags per
area and express level as value of these bits. I’m not sure
if the second is even possible with ETW macros. Any other
possibility? And are there any non-obvious consequences?

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.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@windows.microsoft.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:
xxxxx@hollistech.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: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

SoftICE Classic is a kernel debugger, so, it will handle kernel-side KD
extensions ok. Now, if you have Visual SoftICE, then it can handle user-side
as well. Now, DriverMonitor can capture debug prints too, and BoundsChecker
can catch a lot of system level events.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Michal Vodicka
Sent: Monday, February 16, 2004 6:08 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW and debug prints


From:
xxxxx@windows.microsoft.com[SMTP:xxxxx@windows.microsoft.com]
Reply To: xxxxx@lists.osr.com
Sent: Monday, February 16, 2004 11:32 PM
To: xxxxx@lists.osr.com
Subject: RE: [ntdev] ETW and debug prints

>Sorry, I presumed it is obvious. They capture kernel DbgPrint and user
mode
>OutputDebugPrint and display them.
Well OK I do know the obvious :-), but I don’t know if there is
anywhere they could call for example Traceprt.

Ah so. Probably not; SoftICE can call a KD extension but I guess it isn’t
sufficient.

Thanks for answers, it seems I’ll have to try it to see more. The last
question: currently we’re using debug areas and every area has assigned
debug level (as trace, warning, error). One application/driver usually uses
several areas. ETW seems to use bit flags and one level which is global for
all. How to map our approach to it? I see two possibilities – use one GUID
per area and use level only or reserve 3 bits/flags per area and express
level as value of these bits. I’m not sure if the second is even possible
with ETW macros. Any other possibility? And are there any non-obvious
consequences?

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.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@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

> -----Original Message-----

From: Ian Service [mailto:xxxxx@windows.microsoft.com]
Sent: Tuesday, February 17, 2004 9:24 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW and debug prints

That macro modification is variant of one that I have seen
before and should work. One very simple model that gives you
a flags worth of components is a bit per component plus use
levels for the depth of tracing.

Can you not set the levels from the Advanced Log Session options?

OK you’ve lost me again. The levels are not defined using
WPP_DEFINE_BIT(xxx), right? Is there some other mechanism to put levels
under WPP control?

TraceView does show a level setting. But where is it coming from?

=====================
Mark Roddy

I misunderstood your earlier statement about setting the levels.

Unlike flags WPP treats levels as pure numeric values and does not play
any symbol name munging so you can in fact use a normal define or
variable for levels. This model suits some existing code. The only trick
is helping the WPP macros find the appropriate data structure when only
levels are used, see the use of DUMMY (the name is irrelevant) below and
remember I wanted to show it working in shipping WPP’s

Normally we try to use a standard set of levels and those are exported
in evntrace.h from server 2003 based DDK’s onwards. This is included by
the trace header files anyway so its readily available.

Symbols like TRACE_LEVEL_ERROR, and there are a block of them.

Now what I normally do because we don’t have a level specific macro
built in to all versions of tracing (I realize one could be added but
this works for back revs)is -

#define WPP_CONTROL_GUIDS \

WPP_DEFINE_CONTROL_GUID(CtlGuid,(a044090f,3d9d,48cf,b7ee,9fb114702dc1),\
WPP_DEFINE_BIT(DUMMY))

#define WPP_LEVEL_LOGGER(lvl) (WPP_CONTROL(WPP_BIT_ ## DUMMY).Logger),
#define WPP_LEVEL_ENABLED(lvl) WPP_CONTROL(WPP_BIT_ ## DUMMY).Level >=
lvl

//
// The usual stuff
//
DoTraceMessage(TRACE_LEVEL_ERROR, “Hello, %s %d”, “World”, i);

Hope this answers the correct question this time.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Tuesday, February 17, 2004 7:09 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW and debug prints

-----Original Message-----
From: Ian Service [mailto:xxxxx@windows.microsoft.com]
Sent: Tuesday, February 17, 2004 9:24 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW and debug prints

That macro modification is variant of one that I have seen
before and should work. One very simple model that gives you
a flags worth of components is a bit per component plus use
levels for the depth of tracing.

Can you not set the levels from the Advanced Log Session options?

OK you’ve lost me again. The levels are not defined using
WPP_DEFINE_BIT(xxx), right? Is there some other mechanism to put levels
under WPP control?

TraceView does show a level setting. But where is it coming from?

=====================
Mark Roddy


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Ok, so actually this was my confusion. While ETW levels are ‘not-munged’
they are controlled (as in set) by ETW. Duh. So the advice to map your
programs levels to the ‘standard’ ETW levels makes a lot of sense. (Too bad
that traceview can’t display levels/flags as anything other than hex
values.) So I have flags/levels working, and they can be controlled via the
traceview application and life is near-bliss, and it really wasn’t so
horrible getting here, and I take back almost everything bad I ever said
about ETW because now ETW and I are real close. We still don’t take showers
together, but we get along.

But I’m not quite where I want to be yet. I’m interested in how Michal
Vodicka manages with his mission to get per-component levels working, as
that is the ideal flexibility for a trace logging service. Also, I need
logging to start when my driver starts, even if that is boot start, and have
all trace messages spooled (up to some configurable limit) until a consumer
is available. I think I asked about this at DevCon and I think the answer
was ‘no not really’. If that is true then this remains a major hurdle for
whole classes of device drivers (see the storage stack.)

Thanks to Ian and Henry for taking the time to provide detailed information
here about stuff actually relevant to NT kernel development. And thanks to
all those who provided lots of good tips and tricks to get ETW functional.
It has been a pleasure to actually learn something on this list.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ian Service
Sent: Tuesday, February 17, 2004 10:35 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW and debug prints

I misunderstood your earlier statement about setting the levels.

Unlike flags WPP treats levels as pure numeric values and
does not play any symbol name munging so you can in fact use
a normal define or variable for levels. This model suits some
existing code. The only trick is helping the WPP macros find
the appropriate data structure when only levels are used, see
the use of DUMMY (the name is irrelevant) below and remember
I wanted to show it working in shipping WPP’s

Normally we try to use a standard set of levels and those are
exported in evntrace.h from server 2003 based DDK’s onwards.
This is included by the trace header files anyway so its
readily available.

Symbols like TRACE_LEVEL_ERROR, and there are a block of them.

Now what I normally do because we don’t have a level specific
macro built in to all versions of tracing (I realize one
could be added but this works for back revs)is -

#define WPP_CONTROL_GUIDS \

WPP_DEFINE_CONTROL_GUID(CtlGuid,(a044090f,3d9d,48cf,b7ee,9fb11
4702dc1),\
WPP_DEFINE_BIT(DUMMY))

#define WPP_LEVEL_LOGGER(lvl) (WPP_CONTROL(WPP_BIT_ ##
DUMMY).Logger), #define WPP_LEVEL_ENABLED(lvl)
WPP_CONTROL(WPP_BIT_ ## DUMMY).Level >= lvl

//
// The usual stuff
//
DoTraceMessage(TRACE_LEVEL_ERROR, “Hello, %s %d”, “World”, i);

Hope this answers the correct question this time.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Tuesday, February 17, 2004 7:09 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW and debug prints

> -----Original Message-----
> From: Ian Service [mailto:xxxxx@windows.microsoft.com]
> Sent: Tuesday, February 17, 2004 9:24 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] ETW and debug prints
>
> That macro modification is variant of one that I have seen
before and
> should work. One very simple model that gives you a flags worth of
> components is a bit per component plus use levels for the depth of
> tracing.
>
> Can you not set the levels from the Advanced Log Session options?
>

OK you’ve lost me again. The levels are not defined using
WPP_DEFINE_BIT(xxx), right? Is there some other mechanism to
put levels under WPP control?

TraceView does show a level setting. But where is it coming from?

=====================
Mark Roddy

>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@windows.microsoft.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:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com

> ----------

From: xxxxx@hollistech.com[SMTP:xxxxx@hollistech.com]
Reply To: xxxxx@lists.osr.com
Sent: Wednesday, February 18, 2004 2:19 PM
To: xxxxx@lists.osr.com
Subject: RE: [ntdev] ETW and debug prints

But I’m not quite where I want to be yet. I’m interested in how Michal
Vodicka manages with his mission to get per-component levels working, as
that is the ideal flexibility for a trace logging service.

Unfortunately, I don’t have time to experiment with it just now. Hopefully
in the future. If somebody else finds an usable solution in the meantime,
I’d be really interested.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

I decided to start playing with ETW after reading about it here for the
last few weeks. Instead of trying it on a driver, I decided to try it
from user mode using the example in MSDN so that I could get a better
understanding of the process and tools involved. Unfortunately, it
doesn’t work out of the box. I set up a project in VS.NET and generated
the tmh files. So far so good, but when the complier ran I got the
following:

Compiling…
wppex2.cpp
f:\interop\wppex\wppex2.cpp(11) : error C2065: ‘WPP_ANNOTATE_wppex2_cpp’
: undeclared identifier
f:\interop\wppex\wppex2.cpp(11) : error C2065: ‘WPP_CALL_wppex2_cpp’ :
undeclared identifier
f:\interop\wppex\wppex2.cpp(11) : error C2065: ‘Error’ : undeclared
identifier
wppex.cpp
f:\interop\wppex\wppex.cpp(26) : error C2065: ‘WPP_ANNOTATE_wppex_cpp’ :
undeclared identifier
f:\interop\wppex\wppex.cpp(26) : error C2065: ‘WPP_CALL_wppex_cpp’ :
undeclared identifier
f:\interop\wppex\wppex.cpp(26) : error C2065: ‘Unusual’ : undeclared
identifier
f:\interop\wppex\wppex.cpp(29) : error C2065: ‘Noise’ : undeclared
identifier

(The lines above are the lines that call DoTraceMessage)

I did get this working by setting up SOURCES file and using the DDK
compiler, but this is not feasible for doing ETW with large project.
Anybody have any clues on how to get this to work using VS?

Chapman Mays

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Wednesday, February 18, 2004 5:30 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW and debug prints

> ----------
> From: xxxxx@hollistech.com[SMTP:xxxxx@hollistech.com]
> Reply To: xxxxx@lists.osr.com
> Sent: Wednesday, February 18, 2004 2:19 PM
> To: xxxxx@lists.osr.com
> Subject: RE: [ntdev] ETW and debug prints
>
> But I’m not quite where I want to be yet. I’m interested in
how Michal
> Vodicka manages with his mission to get per-component
levels working,
> as that is the ideal flexibility for a trace logging service.
>
Unfortunately, I don’t have time to experiment with it just
now. Hopefully in the future. If somebody else finds an
usable solution in the meantime, I’d be really interested.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.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@transat-tech.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

How many times do people have to say that using Visual Studio to write
drivers is not supported by Microsoft. Only the compiler that comes
with the DDK is supported. I and other have techniques to permit use of
Visual Studio as the editor, but any other solution is not supported and
definitely not recommended.

“Chapman Mays” wrote in message
news:xxxxx@ntdev…
> I decided to start playing with ETW after reading about it here for
the
> last few weeks. Instead of trying it on a driver, I decided to try it
> from user mode using the example in MSDN so that I could get a better
> understanding of the process and tools involved. Unfortunately, it
> doesn’t work out of the box. I set up a project in VS.NET and
generated
> the tmh files. So far so good, but when the complier ran I got the
> following:
>
> Compiling…
> wppex2.cpp
> f:\interop\wppex\wppex2.cpp(11) : error C2065:
‘WPP_ANNOTATE_wppex2_cpp’
> : undeclared identifier
> f:\interop\wppex\wppex2.cpp(11) : error C2065: ‘WPP_CALL_wppex2_cpp’ :
> undeclared identifier
> f:\interop\wppex\wppex2.cpp(11) : error C2065: ‘Error’ : undeclared
> identifier
> wppex.cpp
> f:\interop\wppex\wppex.cpp(26) : error C2065: ‘WPP_ANNOTATE_wppex_cpp’
:
> undeclared identifier
> f:\interop\wppex\wppex.cpp(26) : error C2065: ‘WPP_CALL_wppex_cpp’ :
> undeclared identifier
> f:\interop\wppex\wppex.cpp(26) : error C2065: ‘Unusual’ : undeclared
> identifier
> f:\interop\wppex\wppex.cpp(29) : error C2065: ‘Noise’ : undeclared
> identifier
>
> (The lines above are the lines that call DoTraceMessage)
>
> I did get this working by setting up SOURCES file and using the DDK
> compiler, but this is not feasible for doing ETW with large project.
> Anybody have any clues on how to get this to work using VS?
>
> Chapman Mays
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Michal
Vodicka
> > Sent: Wednesday, February 18, 2004 5:30 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] ETW and debug prints
> >
> >
> > > ----------
> > > From: xxxxx@hollistech.com[SMTP:xxxxx@hollistech.com]
> > > Reply To: xxxxx@lists.osr.com
> > > Sent: Wednesday, February 18, 2004 2:19 PM
> > > To: xxxxx@lists.osr.com
> > > Subject: RE: [ntdev] ETW and debug prints
> > >
> > > But I’m not quite where I want to be yet. I’m interested in
> > how Michal
> > > Vodicka manages with his mission to get per-component
> > levels working,
> > > as that is the ideal flexibility for a trace logging service.
> > >
> > Unfortunately, I don’t have time to experiment with it just
> > now. Hopefully in the future. If somebody else finds an
> > usable solution in the meantime, I’d be really interested.
> >
> > Best regards,
> >
> > Michal Vodicka
> > STMicroelectronics Design and Application s.r.o.
> > [michal.vodicka@st.com, http:://www.st.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@transat-tech.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

There is a misunderstanding somewhere, I don’t think you read my
question carefully. Granted, I am asking about a user mode problem on a
driver development list, but I think it is on-topic regarding the ETW
framework given the questions that have come up regarding its use.

I thought I was being clear that I was testing a simple USER MODE
program which uses ETW, the source for which came directly from the
Event Tracing section of MSDN.

Why should I build a driver when a simple 30 line console app will let
me do quick turns in trying different things? I certainly don’t (and
didn’t) advocate trying to build drivers outside of the DDK environment.
I’m just trying to figure out why the DDK compiler works when building a
console application and the VS compiler doesn’t.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David J. Craig
Sent: Thursday, February 19, 2004 2:06 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] ETW and debug prints

How many times do people have to say that using Visual Studio
to write drivers is not supported by Microsoft. Only the
compiler that comes with the DDK is supported. I and other
have techniques to permit use of Visual Studio as the editor,
but any other solution is not supported and definitely not
recommended.

“Chapman Mays” wrote in message
> news:xxxxx@ntdev…
> > I decided to start playing with ETW after reading about it here for
> the
> > last few weeks. Instead of trying it on a driver, I decided
> to try it
> > from user mode using the example in MSDN so that I could
> get a better
> > understanding of the process and tools involved. Unfortunately, it
> > doesn’t work out of the box. I set up a project in VS.NET and
> generated
> > the tmh files. So far so good, but when the complier ran I got the
> > following:
> >
> > Compiling…
> > wppex2.cpp
> > f:\interop\wppex\wppex2.cpp(11) : error C2065:
> ‘WPP_ANNOTATE_wppex2_cpp’
> > : undeclared identifier
> > f:\interop\wppex\wppex2.cpp(11) : error C2065:
> ‘WPP_CALL_wppex2_cpp’ :
> > undeclared identifier
> > f:\interop\wppex\wppex2.cpp(11) : error C2065: ‘Error’ : undeclared
> > identifier wppex.cpp
> > f:\interop\wppex\wppex.cpp(26) : error C2065:
> ‘WPP_ANNOTATE_wppex_cpp’
> :
> > undeclared identifier
> > f:\interop\wppex\wppex.cpp(26) : error C2065:
> ‘WPP_CALL_wppex_cpp’ :
> > undeclared identifier
> > f:\interop\wppex\wppex.cpp(26) : error C2065: ‘Unusual’ :
> undeclared
> > identifier
> > f:\interop\wppex\wppex.cpp(29) : error C2065: ‘Noise’ : undeclared
> > identifier
> >
> > (The lines above are the lines that call DoTraceMessage)
> >
> > I did get this working by setting up SOURCES file and using the DDK
> > compiler, but this is not feasible for doing ETW with large
> project.
> > Anybody have any clues on how to get this to work using VS?
> >
> > Chapman Mays
> >
> >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Michal
> Vodicka
> > > Sent: Wednesday, February 18, 2004 5:30 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: RE: [ntdev] ETW and debug prints
> > >
> > >
> > > > ----------
> > > > From: xxxxx@hollistech.com[SMTP:xxxxx@hollistech.com]
> > > > Reply To: xxxxx@lists.osr.com
> > > > Sent: Wednesday, February 18, 2004 2:19 PM
> > > > To: xxxxx@lists.osr.com
> > > > Subject: RE: [ntdev] ETW and debug prints
> > > >
> > > > But I’m not quite where I want to be yet. I’m interested in
> > > how Michal
> > > > Vodicka manages with his mission to get per-component
> > > levels working,
> > > > as that is the ideal flexibility for a trace logging service.
> > > >
> > > Unfortunately, I don’t have time to experiment with it just now.
> > > Hopefully in the future. If somebody else finds an usable
> solution
> > > in the meantime, I’d be really interested.
> > >
> > > Best regards,
> > >
> > > Michal Vodicka
> > > STMicroelectronics Design and Application s.r.o.
> > > [michal.vodicka@st.com, http:://www.st.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@transat-tech.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: xxxxx@transat-tech.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

While David said is correct, Chapman actually wanted to build a user
mode application to use tracing, and as software tracing is supported in
both user mode drivers and applications what Chapman asked is possible;
though then it’s usually easier to just use the DDK style build
environment.

Actually writing a trivial application is a good way to learn and many
folks have both user mode and drivers and like to see the traces
intermixed.

Anyway the problem I think Chapman ran up against is a conflict between
the way WPP software tracing and the VS.NET incremental debug
information works. Simply not selecting /ZI (Program database for Edit
and Continue) will correct this. That’s under right click on the Project
property pages, then select C/C++, select general and change “Debug
Information Format”.
(I just tried to be sure and saw the same effects)

Note what I usually suggest to make things easier is that you also use
the “Build Events” in the same set of property pages to set up the
equivalent of the the RUN_WPP line from sources.
Placewheretracewppis\TraceWpp -cfgdir:“place where the.TPLfiles are”
sourcefiles etc.

That will build the tmh files for you.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David J. Craig
Sent: Thursday, February 19, 2004 12:06 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] ETW and debug prints

How many times do people have to say that using Visual Studio to write
drivers is not supported by Microsoft. Only the compiler that comes
with the DDK is supported. I and other have techniques to permit use of
Visual Studio as the editor, but any other solution is not supported and
definitely not recommended.

“Chapman Mays” wrote in message
news:xxxxx@ntdev…
> I decided to start playing with ETW after reading about it here for
the
> last few weeks. Instead of trying it on a driver, I decided to try it
> from user mode using the example in MSDN so that I could get a better
> understanding of the process and tools involved. Unfortunately, it
> doesn’t work out of the box. I set up a project in VS.NET and
generated
> the tmh files. So far so good, but when the complier ran I got the
> following:
>
> Compiling…
> wppex2.cpp
> f:\interop\wppex\wppex2.cpp(11) : error C2065:
‘WPP_ANNOTATE_wppex2_cpp’
> : undeclared identifier
> f:\interop\wppex\wppex2.cpp(11) : error C2065: ‘WPP_CALL_wppex2_cpp’ :
> undeclared identifier
> f:\interop\wppex\wppex2.cpp(11) : error C2065: ‘Error’ : undeclared
> identifier
> wppex.cpp
> f:\interop\wppex\wppex.cpp(26) : error C2065: ‘WPP_ANNOTATE_wppex_cpp’
:
> undeclared identifier
> f:\interop\wppex\wppex.cpp(26) : error C2065: ‘WPP_CALL_wppex_cpp’ :
> undeclared identifier
> f:\interop\wppex\wppex.cpp(26) : error C2065: ‘Unusual’ : undeclared
> identifier
> f:\interop\wppex\wppex.cpp(29) : error C2065: ‘Noise’ : undeclared
> identifier
>
> (The lines above are the lines that call DoTraceMessage)
>
> I did get this working by setting up SOURCES file and using the DDK
> compiler, but this is not feasible for doing ETW with large project.
> Anybody have any clues on how to get this to work using VS?
>
> Chapman Mays
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Michal
Vodicka
> > Sent: Wednesday, February 18, 2004 5:30 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] ETW and debug prints
> >
> >
> > > ----------
> > > From: xxxxx@hollistech.com[SMTP:xxxxx@hollistech.com]
> > > Reply To: xxxxx@lists.osr.com
> > > Sent: Wednesday, February 18, 2004 2:19 PM
> > > To: xxxxx@lists.osr.com
> > > Subject: RE: [ntdev] ETW and debug prints
> > >
> > > But I’m not quite where I want to be yet. I’m interested in
> > how Michal
> > > Vodicka manages with his mission to get per-component
> > levels working,
> > > as that is the ideal flexibility for a trace logging service.
> > >
> > Unfortunately, I don’t have time to experiment with it just
> > now. Hopefully in the future. If somebody else finds an
> > usable solution in the meantime, I’d be really interested.
> >
> > Best regards,
> >
> > Michal Vodicka
> > STMicroelectronics Design and Application s.r.o.
> > [michal.vodicka@st.com, http:://www.st.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@transat-tech.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: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Thanks Ian, that is exactly what was needed, and sure wasn’t very clear
from the error output that I had. It would certainly be a good idea to
get a real sample into the Platform SDK as well as a note in the “Build
the Project for Tracing” entry in the MSDN library that warns about this
behavior.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ian Service
Sent: Thursday, February 19, 2004 2:30 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW and debug prints

While David said is correct, Chapman actually wanted to build
a user mode application to use tracing, and as software
tracing is supported in both user mode drivers and
applications what Chapman asked is possible; though then it’s
usually easier to just use the DDK style build environment.

Actually writing a trivial application is a good way to learn
and many folks have both user mode and drivers and like to
see the traces intermixed.

Anyway the problem I think Chapman ran up against is a
conflict between the way WPP software tracing and the VS.NET
incremental debug information works. Simply not selecting /ZI
(Program database for Edit and Continue) will correct this.
That’s under right click on the Project property pages, then
select C/C++, select general and change “Debug Information
Format”. (I just tried to be sure and saw the same effects)

Note what I usually suggest to make things easier is that you
also use the “Build Events” in the same set of property pages
to set up the equivalent of the the RUN_WPP line from
sources. Placewheretracewppis\TraceWpp -cfgdir:“place where
the.TPLfiles are” sourcefiles etc.

That will build the tmh files for you.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David J. Craig
Sent: Thursday, February 19, 2004 12:06 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] ETW and debug prints

How many times do people have to say that using Visual Studio
to write drivers is not supported by Microsoft. Only the
compiler that comes with the DDK is supported. I and other
have techniques to permit use of Visual Studio as the editor,
but any other solution is not supported and definitely not
recommended.

“Chapman Mays” wrote in message
> news:xxxxx@ntdev…
> > I decided to start playing with ETW after reading about it here for
> the
> > last few weeks. Instead of trying it on a driver, I decided
> to try it
> > from user mode using the example in MSDN so that I could
> get a better
> > understanding of the process and tools involved. Unfortunately, it
> > doesn’t work out of the box. I set up a project in VS.NET and
> generated
> > the tmh files. So far so good, but when the complier ran I got the
> > following:
> >
> > Compiling…
> > wppex2.cpp
> > f:\interop\wppex\wppex2.cpp(11) : error C2065:
> ‘WPP_ANNOTATE_wppex2_cpp’
> > : undeclared identifier
> > f:\interop\wppex\wppex2.cpp(11) : error C2065:
> ‘WPP_CALL_wppex2_cpp’ :
> > undeclared identifier
> > f:\interop\wppex\wppex2.cpp(11) : error C2065: ‘Error’ : undeclared
> > identifier wppex.cpp
> > f:\interop\wppex\wppex.cpp(26) : error C2065:
> ‘WPP_ANNOTATE_wppex_cpp’
> :
> > undeclared identifier
> > f:\interop\wppex\wppex.cpp(26) : error C2065:
> ‘WPP_CALL_wppex_cpp’ :
> > undeclared identifier
> > f:\interop\wppex\wppex.cpp(26) : error C2065: ‘Unusual’ :
> undeclared
> > identifier
> > f:\interop\wppex\wppex.cpp(29) : error C2065: ‘Noise’ : undeclared
> > identifier
> >
> > (The lines above are the lines that call DoTraceMessage)
> >
> > I did get this working by setting up SOURCES file and using the DDK
> > compiler, but this is not feasible for doing ETW with large
> project.
> > Anybody have any clues on how to get this to work using VS?
> >
> > Chapman Mays
> >
> >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Michal
> Vodicka
> > > Sent: Wednesday, February 18, 2004 5:30 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: RE: [ntdev] ETW and debug prints
> > >
> > >
> > > > ----------
> > > > From: xxxxx@hollistech.com[SMTP:xxxxx@hollistech.com]
> > > > Reply To: xxxxx@lists.osr.com
> > > > Sent: Wednesday, February 18, 2004 2:19 PM
> > > > To: xxxxx@lists.osr.com
> > > > Subject: RE: [ntdev] ETW and debug prints
> > > >
> > > > But I’m not quite where I want to be yet. I’m interested in
> > > how Michal
> > > > Vodicka manages with his mission to get per-component
> > > levels working,
> > > > as that is the ideal flexibility for a trace logging service.
> > > >
> > > Unfortunately, I don’t have time to experiment with it just now.
> > > Hopefully in the future. If somebody else finds an usable
> solution
> > > in the meantime, I’d be really interested.
> > >
> > > Best regards,
> > >
> > > Michal Vodicka
> > > STMicroelectronics Design and Application s.r.o.
> > > [michal.vodicka@st.com, http:://www.st.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@transat-tech.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: xxxxx@windows.microsoft.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: xxxxx@transat-tech.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

It’s just a shell! You can configure it any way you want. All you have to do
is to frig your executable path, and the MSVC shell will use the DDK
compiler. Tools…Options…Directories… It’s not that hard ! If you’re
really suspicious of workspaces and projects, you can always put in a call
to build.exe in your custom step.

If you use MSVC, you get an editor; integration with source control; a
workspace; a project; a browser; and more. You also get to set up
multiple-project workspaces with automatic handling of inter-project
dependencies. We build the BoundsChecker, TrueCoverage and TrueTime drivers
with MSVC and we use the DDK compiler - no problem.

And if you use MSVC.NET, you have the added benefit of having BoundsChecker,
TrueTime, TrueCoverage and DriverMonitor integrated within the MSVC.NET
shell. :slight_smile:

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of David J. Craig
Sent: Thursday, February 19, 2004 3:06 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] ETW and debug prints

How many times do people have to say that using Visual Studio to write
drivers is not supported by Microsoft. Only the compiler that comes
with the DDK is supported. I and other have techniques to permit use of
Visual Studio as the editor, but any other solution is not supported and
definitely not recommended.

“Chapman Mays” wrote in message
news:xxxxx@ntdev…
> I decided to start playing with ETW after reading about it here for
the
> last few weeks. Instead of trying it on a driver, I decided to try it
> from user mode using the example in MSDN so that I could get a better
> understanding of the process and tools involved. Unfortunately, it
> doesn’t work out of the box. I set up a project in VS.NET and
generated
> the tmh files. So far so good, but when the complier ran I got the
> following:
>
> Compiling…
> wppex2.cpp
> f:\interop\wppex\wppex2.cpp(11) : error C2065:
‘WPP_ANNOTATE_wppex2_cpp’
> : undeclared identifier
> f:\interop\wppex\wppex2.cpp(11) : error C2065: ‘WPP_CALL_wppex2_cpp’ :
> undeclared identifier
> f:\interop\wppex\wppex2.cpp(11) : error C2065: ‘Error’ : undeclared
> identifier
> wppex.cpp
> f:\interop\wppex\wppex.cpp(26) : error C2065: ‘WPP_ANNOTATE_wppex_cpp’
:
> undeclared identifier
> f:\interop\wppex\wppex.cpp(26) : error C2065: ‘WPP_CALL_wppex_cpp’ :
> undeclared identifier
> f:\interop\wppex\wppex.cpp(26) : error C2065: ‘Unusual’ : undeclared
> identifier
> f:\interop\wppex\wppex.cpp(29) : error C2065: ‘Noise’ : undeclared
> identifier
>
> (The lines above are the lines that call DoTraceMessage)
>
> I did get this working by setting up SOURCES file and using the DDK
> compiler, but this is not feasible for doing ETW with large project.
> Anybody have any clues on how to get this to work using VS?
>
> Chapman Mays
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Michal
Vodicka
> > Sent: Wednesday, February 18, 2004 5:30 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] ETW and debug prints
> >
> >
> > > ----------
> > > From: xxxxx@hollistech.com[SMTP:xxxxx@hollistech.com]
> > > Reply To: xxxxx@lists.osr.com
> > > Sent: Wednesday, February 18, 2004 2:19 PM
> > > To: xxxxx@lists.osr.com
> > > Subject: RE: [ntdev] ETW and debug prints
> > >
> > > But I’m not quite where I want to be yet. I’m interested in
> > how Michal
> > > Vodicka manages with his mission to get per-component
> > levels working,
> > > as that is the ideal flexibility for a trace logging service.
> > >
> > Unfortunately, I don’t have time to experiment with it just
> > now. Hopefully in the future. If somebody else finds an
> > usable solution in the meantime, I’d be really interested.
> >
> > Best regards,
> >
> > Michal Vodicka
> > STMicroelectronics Design and Application s.r.o.
> > [michal.vodicka@st.com, http:://www.st.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@transat-tech.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: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

Mark,

Sorry for the long delay before my answer, I was on vacation. Here’s
the simplest method to use different levels in multiple components in a
single binary:

Instead of only defining one GUID in the WPP_CONTROL_GUIDS macro, define
multiple GUIDS as follows:

#define WPP_CONTROL_GUIDS \
WPP_DEFINE_CONTROL_GUID(One,(0e85a5a4,4d5c,44b7,8bda,5b7ab54f7e90),
\
WPP_DEFINE_BIT(Component1_Error)
\
)
\
WPP_DEFINE_CONTROL_GUID(Two,(0e85a5a4,4d5c,44b7,8bda,5b7ab54f7e91),
\
WPP_DEFINE_BIT(Component2_Error)
\
)

What the above line does is prepare multiple individual control GUIDs
for tracing in the binary. All the extra registration is automatic. As
long as all your BITs are defined with unique names, then you just use
the appropriate names in your tracing functions to get trace statement
associated with the appropriate control GUID. Since each control GUID
has its own LEVEL setting, this allows you to get any level of control
you need.

Hth,
.

This posting is provided “AS IS” with no warranties, and confers no
rights.
Use of included code samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

-----Original Message-----
From: Mark Roddy [mailto:xxxxx@hollistech.com]
Sent: Wednesday, February 18, 2004 5:19 AM
Subject: RE: ETW and debug prints

Ok, so actually this was my confusion. While ETW levels are ‘not-munged’
they are controlled (as in set) by ETW. Duh. So the advice to map your
programs levels to the ‘standard’ ETW levels makes a lot of sense. (Too
bad that traceview can’t display levels/flags as anything other than hex
values.) So I have flags/levels working, and they can be controlled via
the traceview application and life is near-bliss, and it really wasn’t
so horrible getting here, and I take back almost everything bad I ever
said about ETW because now ETW and I are real close. We still don’t take
showers together, but we get along.

But I’m not quite where I want to be yet. I’m interested in how Michal
Vodicka manages with his mission to get per-component levels working, as
that is the ideal flexibility for a trace logging service. Also, I need
logging to start when my driver starts, even if that is boot start, and
have all trace messages spooled (up to some configurable limit) until a
consumer is available. I think I asked about this at DevCon and I think
the answer was ‘no not really’. If that is true then this remains a
major hurdle for whole classes of device drivers (see the storage
stack.)

Thanks to Ian and Henry for taking the time to provide detailed
information here about stuff actually relevant to NT kernel development.
And thanks to all those who provided lots of good tips and tricks to get
ETW functional.
It has been a pleasure to actually learn something on this list.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ian Service
Sent: Tuesday, February 17, 2004 10:35 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW and debug prints

I misunderstood your earlier statement about setting the levels.

Unlike flags WPP treats levels as pure numeric values and does not
play any symbol name munging so you can in fact use a normal define or

variable for levels. This model suits some existing code. The only
trick is helping the WPP macros find the appropriate data structure
when only levels are used, see the use of DUMMY (the name is
irrelevant) below and remember I wanted to show it working in shipping

WPP’s

Normally we try to use a standard set of levels and those are exported

in evntrace.h from server 2003 based DDK’s onwards.
This is included by the trace header files anyway so its readily
available.

Symbols like TRACE_LEVEL_ERROR, and there are a block of them.

Now what I normally do because we don’t have a level specific macro
built in to all versions of tracing (I realize one could be added but
this works for back revs)is -

#define WPP_CONTROL_GUIDS \

WPP_DEFINE_CONTROL_GUID(CtlGuid,(a044090f,3d9d,48cf,b7ee,9fb11
4702dc1),\
WPP_DEFINE_BIT(DUMMY))

#define WPP_LEVEL_LOGGER(lvl) (WPP_CONTROL(WPP_BIT_ ## DUMMY).Logger),

#define WPP_LEVEL_ENABLED(lvl) WPP_CONTROL(WPP_BIT_ ## DUMMY).Level >=

lvl

//
// The usual stuff
//
DoTraceMessage(TRACE_LEVEL_ERROR, “Hello, %s %d”, “World”, i);

Hope this answers the correct question this time.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Tuesday, February 17, 2004 7:09 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW and debug prints

> -----Original Message-----
> From: Ian Service [mailto:xxxxx@windows.microsoft.com]
> Sent: Tuesday, February 17, 2004 9:24 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] ETW and debug prints
>
> That macro modification is variant of one that I have seen
before and
> should work. One very simple model that gives you a flags worth of
> components is a bit per component plus use levels for the depth of
> tracing.
>
> Can you not set the levels from the Advanced Log Session options?
>

OK you’ve lost me again. The levels are not defined using
WPP_DEFINE_BIT(xxx), right? Is there some other mechanism to put
levels under WPP control?

TraceView does show a level setting. But where is it coming from?

=====================
Mark Roddy

>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@windows.microsoft.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:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com