{"id":236,"date":"2007-10-11T11:44:12","date_gmt":"2007-10-11T11:44:12","guid":{"rendered":"https:\/\/driverentry.com.br\/en\/2007\/10\/11\/try-except-finally-and-iowritelogerrorentry-part-2\/"},"modified":"2026-07-27T20:44:45","modified_gmt":"2026-07-27T20:44:45","slug":"try-except-finally-and-iowritelogerrorentry-part-2","status":"publish","type":"post","link":"https:\/\/driverentry.com.br\/en\/2007\/10\/11\/try-except-finally-and-iowritelogerrorentry-part-2\/","title":{"rendered":"Try, Except, Finally and IoWriteLogErrorEntry (Part 2)"},"content":{"rendered":"
\"\"<\/a><\/div>\n

In the first part of this post, I talked a little bit about the demand and the basic logic involved in creating and sending messages to the system event log. Today I’m going to extend a little longer talking about sending parameters in these events, not just getting stuck with fixed messages defined in the file .mc<\/strong>. Another sample driver is available for downloading at the end of this post.<\/p>\n

Sending Parameters in Messages<\/h3>\n

So far, we have seen how to send fixed strings to EventViewer<\/a>: however, it would be very useful to be able to send strings dynamically generated by the driver. Following the issue of handling exceptions, throughout this post, we will write a function that can be called from the __except<\/strong> block, and thus log which exception was thrown and handled by your driver, so that the administrator can finally know if something wrong is happening. If you do not know what I mean, look at the first part of this post<\/a>.<\/p>\n

Like Jack, the Ripper used to say: “Let’s split it.” First, let’s make the code able to display the event’s exception code. To do this, we must put this information at the allocated package. The dumpdata <\/em>member of the IO_ERROR_LOG_PACKET<\/strong> structure can take binary data to the EventViewer<\/em>. This member is an array of ULONG and has its size defined by the DumpDataSize<\/em> member, which should always be a multiple of sizeof (ULONG)<\/em>. Thinking about our example, the handled exception code could be placed on the first position of this array; that is 0xC0000005<\/em> for “Access Violation”<\/em>. See the following example that adds this functionality. Remember that, in addition to the DumpDataSize<\/em> member properly set, the bytes used by elements of this array should be taken into consideration when determining the package size to be allocated.<\/p>\n

\n
\/****<\/span><\/pre>\n
***     SendHelloEventWithData<\/span><\/pre>\n
**<\/span><\/pre>\n
**      Routine that allocates and sends an event which<\/span><\/pre>\n
**      takes an additional 32-bit parameter.<\/span><\/pre>\n
*\/<\/span><\/pre>\n
 <\/pre>\n
VOID SendHelloEventWithData(IN ULONG    ulData)<\/pre>\n
{<\/pre>\n
    PIO_ERROR_LOG_PACKET    pLogPacket;<\/pre>\n
 <\/pre>\n
    \/\/-f--> It allocates the event entry. We should sum<\/span><\/pre>\n
    \/\/      the used bytes by the DumpData array. That<\/span><\/pre>\n
    \/\/      size should always be a multiple of sizeof(ULONG).<\/span><\/pre>\n
 <\/pre>\n
    pLogPacket = IoAllocateErrorLogEntry(pDriverObj,<\/pre>\n
                                         sizeof<\/span>(IO_ERROR_LOG_PACKET) +<\/pre>\n
                                         sizeof<\/span>(ULONG));<\/pre>\n
 <\/pre>\n
    \/\/-f--> It Initializes the whole structure.<\/span><\/pre>\n
    RtlZeroMemory(pLogPacket, sizeof<\/span>(IO_ERROR_LOG_PACKET));<\/pre>\n
 <\/pre>\n
    \/\/-f--> Puts up the desired message<\/span><\/pre>\n
    pLogPacket->ErrorCode = EVT_HELLO_MESSAGE;<\/pre>\n
 <\/pre>\n
 <\/pre>\n
    \/\/-f--> It fills up the binary dump and its size.<\/span><\/pre>\n
    pLogPacket->DumpData[0<\/span>] = ulData;<\/pre>\n
    pLogPacket->DumpDataSize = sizeof<\/span>(ULONG);<\/pre>\n
 <\/pre>\n
    \/\/-f--> It sends up the event entry to the event list.<\/span><\/pre>\n
    IoWriteErrorLogEntry(pLogPacket);<\/pre>\n
}<\/pre>\n<\/div>\n
If you call this function passing 0x12345678 as a parameter, you will be able to see the sent data as it is shown in the figure below.<\/p>\n
\"\"<\/div>\n
Inserting Strings<\/h3>\n
But where will these strings appear in the event log?<\/strong> We will have to create new messages making use of the strings on our message file. From here, we will build a routine that will be called within the __except<\/strong> block  to log the exception that was handled. Complete the message file with the following text.<\/p>\n
\n
MessageId = 0x0002<\/pre>\n
Facility = DriverEntryLogs<\/pre>\n
Severity = Warning<\/pre>\n
SymbolicName = EVT_EXCEPTION_HANDLED_MESSAGE<\/pre>\n
 <\/pre>\n
Language = Portuguese<\/pre>\n
A casa caiu na rotina %2 com status %3.<\/pre>\n
.<\/pre>\n
Language = English<\/pre>\n
The house fell down at routine %2 with status %3.<\/pre>\n
.<\/pre>\n<\/div>\n
Notice that in these new messages there are these weird %2 and %3. These are the points where the first and second string will be respectively inserted in the message. But why is the first string indicated by %2 instead of %1?<\/strong> The %1 indicator is reserved to map a string with the driver name or device name. That will depend on what object was passed in the IoAllocateErrorLogEntry()<\/a> first parameter. Although %1 is well documented, sometimes the string is not replaced in the message when the driver is starting or ending. Do not ask me why.<\/p>\n
To make our example more complete, it would be very helpful if we could put a string that carried the symbol defined in the ntstatus.h<\/strong> header. So, we would have STATUS_ACCESS_VIOLATION<\/strong> for the exception code 0xc0000005<\/em> in the text displayed by EventViewer<\/em>.<\/p>\n
The first problem is to transform the exception code, which is a numeric value, into a string. This must have been multiple kernel developer’s need, because there is a routine source<\/a> at the OSR Online<\/a> site that does this. To get an idea, this routine is implemented in approximately 2200 lines of code. Is it oo much? Take a look at the beginning of it and you’ll understand it.<\/p>\n
\n
PUCHAR OsrNTStatusToString(NTSTATUS Status) {<\/pre>\n
 <\/pre>\n
    switch<\/span> (Status) {<\/pre>\n
    case<\/span> STATUS_SUCCESS:<\/pre>\n
        return<\/span> \"STATUS_SUCCESS\"<\/span>;<\/pre>\n
    case<\/span> STATUS_WAIT_1:<\/pre>\n
        return<\/span> \"STATUS_WAIT_1\"<\/span>;<\/pre>\n
    case<\/span> STATUS_WAIT_2:<\/pre>\n
        return<\/span> \"STATUS_WAIT_2\"<\/span>;<\/pre>\n
...<\/pre>\n<\/div>\n
After that, we will have to convert these strings from ANSI to UNICODE, but all of this is in the sample code.<\/p>\n
In order the strings can be displayed by the EventViewer<\/em> event, even when the driver is not loaded, they need to be copied into the package. So now, it is necessary to determine the package size that will be allocated using the IoAllocateErrorLogEntry() <\/em>routine. The package size should be added from the number of bytes occupied by the unicode string including the terminating zero. I think it is better for you follow the comments in the source below that already does everything.<\/p>\n
\n
\/****<\/span><\/pre>\n
***     LogExceptionHandled<\/span><\/pre>\n
**<\/span><\/pre>\n
**      This routine receives an NTSTATUS and sends a record to<\/span><\/pre>\n
**      the system event log.<\/span><\/pre>\n
*\/<\/span><\/pre>\n
 <\/pre>\n
VOID LogExceptionHandled(PWSTR     wzFunctionName,<\/pre>\n
                         NTSTATUS  nts)<\/pre>\n
{<\/pre>\n
    UNICODE_STRING          usNtStatus;<\/pre>\n
    ANSI_STRING             asNtStatus;<\/pre>\n
    UCHAR                   ucFinalSize;<\/pre>\n
    PWSTR                   pwzTarget;<\/pre>\n
    PIO_ERROR_LOG_PACKET    pLogPacket;<\/pre>\n
 <\/pre>\n
    \/\/-f--> It initializes an ANSI_STRING with the error code<\/span><\/pre>\n
    RtlInitAnsiString(&asNtStatus,<\/pre>\n
                      OsrNTStatusToString(nts));<\/pre>\n
 <\/pre>\n
 <\/pre>\n
    \/\/-f--> Convert up the string into unicode<\/span><\/pre>\n
    RtlAnsiStringToUnicodeString(&usNtStatus,<\/pre>\n
                                 &asNtStatus,<\/pre>\n
                                 TRUE);<\/pre>\n
 <\/pre>\n
    \/\/-f--> It get the package size, that is, respectively:<\/span><\/pre>\n
    \/\/<\/span><\/pre>\n
    \/\/  IO_ERROR_LOG_PACKET size<\/span><\/pre>\n
    \/\/  DumpData element size<\/span><\/pre>\n
    \/\/  Size of the string containing the error code<\/span><\/pre>\n
 <\/pre>\n
    \/\/      Remember that we should reserve some space for the terminator.<\/span><\/pre>\n
    \/\/  Size of the string containing the routine name that thrown the<\/span><\/pre>\n
    \/\/      exception plus its respective terminator (\/0).<\/span><\/pre>\n
    ucFinalSize = sizeof<\/span>(IO_ERROR_LOG_PACKET) +<\/pre>\n
                  sizeof<\/span>(ULONG) +<\/pre>\n
                  usNtStatus.Length + sizeof<\/span>(WCHAR) +<\/pre>\n
                  (wcslen(wzFunctionName) + 1<\/span>) * sizeof<\/span>(WCHAR);<\/pre>\n
 <\/pre>\n
 <\/pre>\n
    \/\/-f--> It allocates an entry for the event<\/span><\/pre>\n
    pLogPacket = IoAllocateErrorLogEntry(g_pDriverObj,<\/pre>\n
                                         ucFinalSize);<\/pre>\n
 <\/pre>\n
    \/\/-f--> It initializes the whole structure<\/span><\/pre>\n
    RtlZeroMemory(pLogPacket, sizeof<\/span>(IO_ERROR_LOG_PACKET));<\/pre>\n
 <\/pre>\n
    \/\/-f--> It saves the error code into DumpData array<\/span><\/pre>\n
    \/\/      and sets up its size into DumpDataSize member.<\/span><\/pre>\n
    pLogPacket->DumpData[0<\/span>] = nts;<\/pre>\n
    pLogPacket->DumpDataSize = sizeof<\/span>(ULONG);<\/pre>\n
 <\/pre>\n
 <\/pre>\n
    \/\/-f--> It informs where the strings are and how many they are.<\/span><\/pre>\n
    pLogPacket->StringOffset = sizeof<\/span>(IO_ERROR_LOG_PACKET) +<\/pre>\n
                               pLogPacket->DumpDataSize;<\/pre>\n
    pLogPacket->NumberOfStrings = 2<\/span>;<\/pre>\n
 <\/pre>\n
    \/\/-f--> It copies the first string into the package.<\/span><\/pre>\n
    pwzTarget = (PWSTR) ((PCHAR)pLogPacket +<\/pre>\n
                                pLogPacket->StringOffset);<\/pre>\n
    wcscpy(pwzTarget,<\/pre>\n
           wzFunctionName);<\/pre>\n
 <\/pre>\n
    \/\/-f--> It copies the second string into the package.<\/span><\/pre>\n
    pwzTarget += wcslen(wzFunctionName) + 1<\/span>;<\/pre>\n
    wcsncpy(pwzTarget,<\/pre>\n
            usNtStatus.Buffer,<\/pre>\n
            usNtStatus.Length \/ sizeof<\/span>(WCHAR));<\/pre>\n
 <\/pre>\n
 <\/pre>\n
    \/\/-f--> Since the documentation referring to RtlAnsiStringToUnicodeString <\/span><\/pre>\n
    \/\/      doesn't mention there will always be a zero terminator<\/span><\/pre>\n
    \/\/      on the converted string, we cannot assume<\/span><\/pre>\n
    \/\/      that this terminator always be there.<\/span><\/pre>\n
    pwzTarget += usNtStatus.Length \/ sizeof<\/span>(WCHAR);<\/pre>\n
    *pwzTarget = 0<\/span>;<\/pre>\n
 <\/pre>\n
    \/\/-f--> It puts the desired message.<\/span><\/pre>\n
    pLogPacket->ErrorCode = EVT_EXCEPTION_HANDLED_MESSAGE;<\/pre>\n
 <\/pre>\n
 <\/pre>\n
    \/\/-f--> It sends the entry to the event list.<\/span><\/pre>\n
    IoWriteErrorLogEntry(pLogPacket);<\/pre>\n
 <\/pre>\n
    \/\/-f--> It releases the converted string.<\/span><\/pre>\n
    RtlFreeUnicodeString(&usNtStatus);<\/pre>\n
}<\/pre>\n<\/div>\n
In that way, our __except<\/strong> block function, which was provided at the first part of this post, could be set as it is shown below:<\/p>\n
\n
    ...<\/pre>\n
    __except<\/span>(EXCEPTION_EXECUTE_HANDLER)<\/pre>\n
    {<\/pre>\n
        \/\/-f--> Oops! An exception has been thrown. Let's log this,<\/span><\/pre>\n
        \/\/      pretend insanity and just return the exception code.<\/span><\/pre>\n
        nts = GetExceptionCode();<\/pre>\n
 <\/pre>\n
        \/\/-f--> It sends a record to the system event log.<\/span><\/pre>\n
 <\/pre>\n
        LogExceptionHandled(__FUNCTIONW__, nts);<\/pre>\n
        ASSERT(FALSE);<\/pre>\n
    }<\/pre>\n
    ...<\/pre>\n<\/div>\n
Just for a test, let’s make a call to the DupString() <\/em>function passing invalid parameters such as NULL and we will get the following output as it appears below. All the source code of the shown example is available for downloading at the end of this post.<\/p>\n
\"\"<\/div>\n
The End is Near<\/h3>\n
As it was explained in the first part of this post, the event record doesn’t go to the disk synchronously when IoWriteErrorLogEntry()<\/a> function is called; instead, the event record goes to a linked list before going to the disk. If the machine falls down and a dump is generated, we can consult this list with the !errlog<\/strong> in WinDbg<\/a>, which analyzes the generated dump. Cool, let’s see if it works? Let’s send the message below and then dereference a null pointer, just to…<\/strong> The code for this function is written in KillYourSelf ()<\/strong> routine in the sample code available for downloading.<\/p>\n
\n
MessageId = 0x0003<\/pre>\n
Facility = DriverEntryLogs<\/pre>\n
Severity = Error<\/pre>\n
SymbolicName = EVT_GOODBYE_MESSAGE<\/pre>\n
 <\/pre>\n
Language = Portuguese<\/pre>\n
Adeus mundo cruel!<\/pre>\n
.<\/pre>\n
Language = English<\/pre>\n
Goodbye cruel world!<\/pre>\n
.<\/pre>\n<\/div>\n
The KillYourSelf() <\/em>function will only be called when a particular symbol is set, as you can see below. Therefore, if you want to test and see the results with your own eyes modify this symbol definition at the beginning of the source code and redo the test with a test machine.<\/p>\n
\n
 <\/pre>\n
#if<\/span> _WHERE_IS_THE_PENGUIN_<\/pre>\n
    \/\/-f--> Oh! I dream to be a Linux driver. Good-bye cruel world!<\/span><\/pre>\n
    KillYourSelf();<\/pre>\n
#endif<\/span><\/pre>\n<\/div>\n
Inevitably a blue screen will occur, and with it, its memory dump is generated. Opening this dump for analysis using WinDbg<\/strong>, we should use the !errlog<\/strong> command to have the output, as it is shown below.<\/p>\n
\n
Microsoft (R) Windows Debugger  Version 6.7.0005.0<\/pre>\n
Copyright (c) Microsoft Corporation. All rights reserved.<\/pre>\n
 <\/pre>\n
 <\/pre>\n
Loading Dump File [C:\\Documents and Settings\\froberto\\Desktop\\MEMORY.DMP]<\/pre>\n
Kernel Complete Dump File: Full address space is available<\/pre>\n
 <\/pre>\n
Symbol search path is: srv*c:\\symbols*http:\/\/msdl.microsoft.com\/download\/symbols<\/pre>\n
Executable search path is: <\/pre>\n
Windows 2000 Kernel Version 2195 UP Free x86 compatible<\/pre>\n
Product: WinNt<\/pre>\n
Kernel base = 0x80400000 PsLoadedModuleList = 0x8046a4c0<\/pre>\n
Debug session time: Thu Oct 11 11:05:56.375 2007 (GMT-3)<\/pre>\n
System Uptime: 0 days 0:02:06.875<\/pre>\n
Loading Kernel Symbols<\/pre>\n
.................................................................................................<\/pre>\n
Loading User Symbols<\/pre>\n
 <\/pre>\n
*******************************************************************************<\/pre>\n
*                                                                             *<\/pre>\n
*                        Bugcheck Analysis                                    *<\/pre>\n
*                                                                             *<\/pre>\n
*******************************************************************************<\/pre>\n
 <\/pre>\n
Use !analyze -v to get detailed debugging information.<\/pre>\n
 <\/pre>\n
 <\/pre>\n
BugCheck 1E, {c0000005, be552682, 1, 0}<\/pre>\n
 <\/pre>\n
Probably caused by : EventSender.sys ( EventSender!KillYourSelf+2a )<\/pre>\n
 <\/pre>\n
Followup: MachineOwner<\/pre>\n
---------<\/pre>\n
 <\/pre>\n
kd> !errlog<\/pre>\n
PacketAdr  DeviceObj  DriverObj  Function  ErrorCode  UniqueVal  FinalStat<\/pre>\n
81551108   00000000   815c1830    0        402a0001   00000000   00000000<\/pre>\n
        \\Driver\\EventSender<\/pre>\n
        DumpData:  12345678 <\/pre>\n
815b1f88   00000000   815c1830    0        802a0002   00000000   00000000<\/pre>\n
        \\Driver\\EventSender<\/pre>\n
        DumpData:  c0000005 <\/pre>\n
81535248   00000000   815c1830    0        c02a0003   00000000   00000000<\/pre>\n
        \\Driver\\EventSender<\/pre>\n<\/div>\n
At the ErrorCode <\/strong>column, we have the codes that have been defined by the message file compilation and are visible at the header file also generated. Watch up the messages and their identifiers in the excerpt below. As you can see, none of the three test messages used in this example went to the disk. All records were still in memory. Thus, do not expect to see these messages using EventViewer<\/em>; they have not yet been written at the disk yet.<\/p>\n
\n
\/\/<\/span><\/pre>\n
\/\/ MessageId: EVT_HELLO_MESSAGE<\/span><\/pre>\n
\/\/<\/span><\/pre>\n
\/\/ MessageText:<\/span><\/pre>\n
\/\/<\/span><\/pre>\n
\/\/  Ola mundo!<\/span><\/pre>\n
\/\/<\/span><\/pre>\n
#define<\/span> EVT_HELLO_MESSAGE                ((NTSTATUS)0x402A0001L<\/span>)<\/pre>\n
 <\/pre>\n
 <\/pre>\n
\/\/<\/span><\/pre>\n
\/\/ MessageId: EVT_EXCEPTION_HANDLED_MESSAGE<\/span><\/pre>\n
\/\/<\/span><\/pre>\n
\/\/ MessageText:<\/span><\/pre>\n
\/\/<\/span><\/pre>\n
\/\/  A casa caiu na rotina %2 com status %3.<\/span><\/pre>\n
\/\/<\/span><\/pre>\n
#define<\/span> EVT_EXCEPTION_HANDLED_MESSAGE    ((NTSTATUS)0x802A0002L<\/span>)<\/pre>\n
 <\/pre>\n
\/\/<\/span><\/pre>\n
\/\/ MessageId: EVT_GOODBYE_MESSAGE<\/span><\/pre>\n
\/\/<\/span><\/pre>\n
\/\/ MessageText:<\/span><\/pre>\n
\/\/<\/span><\/pre>\n
 <\/pre>\n
\/\/  Adeus mundo cruel!<\/span><\/pre>\n
\/\/<\/span><\/pre>\n
#define<\/span> EVT_GOODBYE_MESSAGE              ((NTSTATUS)0xC02A0003L<\/span>)<\/pre>\n<\/div>\n
Phew! I have thought this post would not finish any more. Once again, I hope this could have helped. CYA!<\/p>\n
EventSender.zip<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
In the first part of this post, I talked a little bit about the demand and the basic logic involved in creating and sending messages to the system event log. Today I’m going to extend a little longer talking about sending parameters in these events, not just getting stuck with fixed messages defined in the […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"pagelayer_contact_templates":[],"_pagelayer_content":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-236","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/236","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/comments?post=236"}],"version-history":[{"count":2,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/236\/revisions"}],"predecessor-version":[{"id":299,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/236\/revisions\/299"}],"wp:attachment":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/media?parent=236"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/categories?post=236"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/tags?post=236"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}