reactos/base/services/eventlog/file.c

1096 lines
31 KiB
C
Raw Permalink Normal View History

/*
* PROJECT: ReactOS EventLog Service
* LICENSE: GPL - See COPYING in the top level directory
* FILE: base/services/eventlog/file.c
* PURPOSE: Event log file support wrappers
* COPYRIGHT: Copyright 2005 Saveliy Tretiakov
* Michael Martin
* Hermes Belusca-Maito
*/
/* INCLUDES ******************************************************************/
#include "eventlog.h"
#include <ndk/iofuncs.h>
#include <ndk/kefuncs.h>
#define NDEBUG
#include <debug.h>
/* LOG FILE LIST - GLOBALS ***************************************************/
static LIST_ENTRY LogFileListHead;
static CRITICAL_SECTION LogFileListCs;
/* LOG FILE LIST - FUNCTIONS *************************************************/
VOID LogfListInitialize(VOID)
{
InitializeCriticalSection(&LogFileListCs);
InitializeListHead(&LogFileListHead);
}
PLOGFILE LogfListItemByName(LPCWSTR Name)
{
PLIST_ENTRY CurrentEntry;
PLOGFILE Item, Result = NULL;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
ASSERT(Name);
EnterCriticalSection(&LogFileListCs);
CurrentEntry = LogFileListHead.Flink;
while (CurrentEntry != &LogFileListHead)
{
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
Item = CONTAINING_RECORD(CurrentEntry, LOGFILE, ListEntry);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
if (Item->LogName && !_wcsicmp(Item->LogName, Name))
{
Result = Item;
break;
}
CurrentEntry = CurrentEntry->Flink;
}
LeaveCriticalSection(&LogFileListCs);
return Result;
}
#if 0
/* Index starting from 1 */
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
DWORD LogfListItemIndexByName(LPCWSTR Name)
{
PLIST_ENTRY CurrentEntry;
DWORD Result = 0;
DWORD i = 1;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
ASSERT(Name);
EnterCriticalSection(&LogFileListCs);
CurrentEntry = LogFileListHead.Flink;
while (CurrentEntry != &LogFileListHead)
{
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
PLOGFILE Item = CONTAINING_RECORD(CurrentEntry, LOGFILE, ListEntry);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
if (Item->LogName && !_wcsicmp(Item->LogName, Name))
{
Result = i;
break;
}
CurrentEntry = CurrentEntry->Flink;
i++;
}
LeaveCriticalSection(&LogFileListCs);
return Result;
}
#endif
/* Index starting from 1 */
PLOGFILE LogfListItemByIndex(DWORD Index)
{
PLIST_ENTRY CurrentEntry;
PLOGFILE Result = NULL;
DWORD i = 1;
EnterCriticalSection(&LogFileListCs);
CurrentEntry = LogFileListHead.Flink;
while (CurrentEntry != &LogFileListHead)
{
if (i == Index)
{
Result = CONTAINING_RECORD(CurrentEntry, LOGFILE, ListEntry);
break;
}
CurrentEntry = CurrentEntry->Flink;
i++;
}
LeaveCriticalSection(&LogFileListCs);
return Result;
}
DWORD LogfListItemCount(VOID)
{
PLIST_ENTRY CurrentEntry;
DWORD i = 0;
EnterCriticalSection(&LogFileListCs);
CurrentEntry = LogFileListHead.Flink;
while (CurrentEntry != &LogFileListHead)
{
CurrentEntry = CurrentEntry->Flink;
i++;
}
LeaveCriticalSection(&LogFileListCs);
return i;
}
static VOID
LogfListAddItem(PLOGFILE Item)
{
EnterCriticalSection(&LogFileListCs);
InsertTailList(&LogFileListHead, &Item->ListEntry);
LeaveCriticalSection(&LogFileListCs);
}
static VOID
LogfListRemoveItem(PLOGFILE Item)
{
EnterCriticalSection(&LogFileListCs);
RemoveEntryList(&Item->ListEntry);
LeaveCriticalSection(&LogFileListCs);
}
/* FUNCTIONS *****************************************************************/
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
// PELF_ALLOCATE_ROUTINE
static
PVOID NTAPI
LogfpAlloc(IN SIZE_T Size,
IN ULONG Flags,
IN ULONG Tag)
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
{
UNREFERENCED_PARAMETER(Tag);
return RtlAllocateHeap(GetProcessHeap(), Flags, Size);
}
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
// PELF_FREE_ROUTINE
static
VOID NTAPI
LogfpFree(IN PVOID Ptr,
IN ULONG Flags,
IN ULONG Tag)
{
UNREFERENCED_PARAMETER(Tag);
RtlFreeHeap(GetProcessHeap(), Flags, Ptr);
}
// PELF_FILE_READ_ROUTINE
static
NTSTATUS NTAPI
LogfpReadFile(IN PEVTLOGFILE LogFile,
IN PLARGE_INTEGER FileOffset,
OUT PVOID Buffer,
IN SIZE_T Length,
OUT PSIZE_T ReadLength OPTIONAL)
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
{
NTSTATUS Status;
PLOGFILE pLogFile = (PLOGFILE)LogFile;
IO_STATUS_BLOCK IoStatusBlock;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
if (ReadLength)
*ReadLength = 0;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
Status = NtReadFile(pLogFile->FileHandle,
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
NULL,
NULL,
NULL,
&IoStatusBlock,
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
Buffer,
Length,
FileOffset,
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
NULL);
if (ReadLength)
*ReadLength = IoStatusBlock.Information;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
return Status;
}
// PELF_FILE_WRITE_ROUTINE
static
NTSTATUS NTAPI
LogfpWriteFile(IN PEVTLOGFILE LogFile,
IN PLARGE_INTEGER FileOffset,
IN PVOID Buffer,
IN SIZE_T Length,
OUT PSIZE_T WrittenLength OPTIONAL)
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
{
NTSTATUS Status;
PLOGFILE pLogFile = (PLOGFILE)LogFile;
IO_STATUS_BLOCK IoStatusBlock;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
if (WrittenLength)
*WrittenLength = 0;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
Status = NtWriteFile(pLogFile->FileHandle,
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
NULL,
NULL,
NULL,
&IoStatusBlock,
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
Buffer,
Length,
FileOffset,
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
NULL);
if (WrittenLength)
*WrittenLength = IoStatusBlock.Information;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
return Status;
}
// PELF_FILE_SET_SIZE_ROUTINE
static
NTSTATUS NTAPI
LogfpSetFileSize(IN PEVTLOGFILE LogFile,
IN ULONG FileSize, // SIZE_T
IN ULONG OldFileSize) // SIZE_T
{
NTSTATUS Status;
PLOGFILE pLogFile = (PLOGFILE)LogFile;
IO_STATUS_BLOCK IoStatusBlock;
FILE_END_OF_FILE_INFORMATION FileEofInfo;
FILE_ALLOCATION_INFORMATION FileAllocInfo;
UNREFERENCED_PARAMETER(OldFileSize);
// FIXME: Should we round up FileSize ??
FileEofInfo.EndOfFile.QuadPart = FileSize;
Status = NtSetInformationFile(pLogFile->FileHandle,
&IoStatusBlock,
&FileEofInfo,
sizeof(FileEofInfo),
FileEndOfFileInformation);
if (!NT_SUCCESS(Status))
return Status;
FileAllocInfo.AllocationSize.QuadPart = FileSize;
Status = NtSetInformationFile(pLogFile->FileHandle,
&IoStatusBlock,
&FileAllocInfo,
sizeof(FileAllocInfo),
FileAllocationInformation);
return Status;
}
// PELF_FILE_FLUSH_ROUTINE
static
NTSTATUS NTAPI
LogfpFlushFile(IN PEVTLOGFILE LogFile,
IN PLARGE_INTEGER FileOffset,
IN ULONG Length)
{
PLOGFILE pLogFile = (PLOGFILE)LogFile;
IO_STATUS_BLOCK IoStatusBlock;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
UNREFERENCED_PARAMETER(FileOffset);
UNREFERENCED_PARAMETER(Length);
return NtFlushBuffersFile(pLogFile->FileHandle, &IoStatusBlock);
}
NTSTATUS
LogfCreate(PLOGFILE* LogFile,
PCWSTR LogName,
PUNICODE_STRING FileName,
ULONG MaxSize,
ULONG Retention,
BOOLEAN Permanent,
BOOLEAN Backup)
{
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
NTSTATUS Status;
OBJECT_ATTRIBUTES ObjectAttributes;
IO_STATUS_BLOCK IoStatusBlock;
FILE_STANDARD_INFORMATION FileStdInfo;
PLOGFILE pLogFile;
SIZE_T LogNameLen;
BOOLEAN CreateNew;
pLogFile = LogfpAlloc(sizeof(*pLogFile), HEAP_ZERO_MEMORY, TAG_ELF);
if (!pLogFile)
{
DPRINT1("Cannot allocate heap!\n");
return STATUS_NO_MEMORY;
}
LogNameLen = (LogName ? wcslen(LogName) : 0) + 1;
pLogFile->LogName = LogfpAlloc(LogNameLen * sizeof(WCHAR), HEAP_ZERO_MEMORY, 0);
if (pLogFile->LogName == NULL)
{
DPRINT1("Cannot allocate heap\n");
Status = STATUS_NO_MEMORY;
goto Quit;
}
if (LogName)
StringCchCopyW(pLogFile->LogName, LogNameLen, LogName);
InitializeObjectAttributes(&ObjectAttributes,
FileName,
OBJ_CASE_INSENSITIVE,
NULL,
NULL);
DPRINT("Going to create or open %wZ\n", FileName);
Status = NtCreateFile(&pLogFile->FileHandle,
Backup ? (GENERIC_READ | SYNCHRONIZE)
: (GENERIC_READ | GENERIC_WRITE | SYNCHRONIZE),
&ObjectAttributes,
&IoStatusBlock,
NULL,
FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ,
Backup ? FILE_OPEN : FILE_OPEN_IF,
FILE_SYNCHRONOUS_IO_NONALERT,
NULL,
0);
if (!NT_SUCCESS(Status))
{
DPRINT1("Cannot create file `%wZ' (Status 0x%08lx)\n", FileName, Status);
goto Quit;
}
CreateNew = (IoStatusBlock.Information == FILE_CREATED);
DPRINT("%wZ %s successfully\n", FileName, CreateNew ? "created" : "opened");
/*
* Retrieve the log file size and check whether the file is not too large;
* this log format only supports files of theoretical size < 0xFFFFFFFF .
*
* As it happens that, on Windows (and ReactOS), retrieving the End-Of-File
* information using NtQueryInformationFile with the FileEndOfFileInformation
* class is invalid (who knows why...), use instead the FileStandardInformation
* class, and the EndOfFile member of the returned FILE_STANDARD_INFORMATION
* structure will give the desired information.
*/
Status = NtQueryInformationFile(pLogFile->FileHandle,
&IoStatusBlock,
&FileStdInfo,
sizeof(FileStdInfo),
FileStandardInformation);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
if (!NT_SUCCESS(Status))
{
DPRINT1("EventLog: NtQueryInformationFile failed (Status 0x%08lx)\n", Status);
goto Quit;
}
if (FileStdInfo.EndOfFile.HighPart != 0)
{
DPRINT1("EventLog: Log `%wZ' is too large.\n", FileName);
Status = STATUS_EVENTLOG_FILE_CORRUPT; // STATUS_FILE_TOO_LARGE;
goto Quit;
}
DPRINT("Initializing LogFile `%S'\n", pLogFile->LogName);
Status = ElfCreateFile(&pLogFile->LogFile,
FileName,
FileStdInfo.EndOfFile.LowPart,
MaxSize,
Retention,
CreateNew,
Backup,
LogfpAlloc,
LogfpFree,
LogfpSetFileSize,
LogfpWriteFile,
LogfpReadFile,
LogfpFlushFile);
if (!NT_SUCCESS(Status))
goto Quit;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
pLogFile->Permanent = Permanent;
RtlInitializeResource(&pLogFile->Lock);
LogfListAddItem(pLogFile);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
Quit:
if (!NT_SUCCESS(Status))
{
if (pLogFile->FileHandle != NULL)
NtClose(pLogFile->FileHandle);
if (pLogFile->LogName)
LogfpFree(pLogFile->LogName, 0, 0);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
LogfpFree(pLogFile, 0, TAG_ELF);
}
else
{
*LogFile = pLogFile;
}
return Status;
}
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
VOID
LogfClose(PLOGFILE LogFile,
BOOLEAN ForceClose)
{
if (LogFile == NULL)
return;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
if (!ForceClose && LogFile->Permanent)
return;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
RtlAcquireResourceExclusive(&LogFile->Lock, TRUE);
LogfListRemoveItem(LogFile);
ElfCloseFile(&LogFile->LogFile);
NtClose(LogFile->FileHandle);
LogfpFree(LogFile->LogName, 0, 0);
RtlDeleteResource(&LogFile->Lock);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
LogfpFree(LogFile, 0, TAG_ELF);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
return;
}
VOID LogfCloseAll(VOID)
{
EnterCriticalSection(&LogFileListCs);
while (!IsListEmpty(&LogFileListHead))
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
{
LogfClose(CONTAINING_RECORD(LogFileListHead.Flink, LOGFILE, ListEntry), TRUE);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
}
LeaveCriticalSection(&LogFileListCs);
DeleteCriticalSection(&LogFileListCs);
}
NTSTATUS
LogfClearFile(PLOGFILE LogFile,
PUNICODE_STRING BackupFileName)
{
NTSTATUS Status;
/* Lock the log file exclusive */
RtlAcquireResourceExclusive(&LogFile->Lock, TRUE);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
if (BackupFileName->Length > 0)
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
{
/* Write a backup file */
Status = LogfBackupFile(LogFile, BackupFileName);
if (!NT_SUCCESS(Status))
{
DPRINT1("LogfBackupFile failed (Status 0x%08lx)\n", Status);
goto Quit;
}
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
}
Status = ElfReCreateFile(&LogFile->LogFile);
if (!NT_SUCCESS(Status))
{
DPRINT1("LogfInitializeNew failed (Status 0x%08lx)\n", Status);
}
Quit:
/* Unlock the log file */
RtlReleaseResource(&LogFile->Lock);
return Status;
}
NTSTATUS
LogfBackupFile(PLOGFILE LogFile,
PUNICODE_STRING BackupFileName)
{
NTSTATUS Status;
LOGFILE BackupLogFile;
OBJECT_ATTRIBUTES ObjectAttributes;
IO_STATUS_BLOCK IoStatusBlock;
DPRINT("LogfBackupFile(%p, %wZ)\n", LogFile, BackupFileName);
/* Lock the log file shared */
RtlAcquireResourceShared(&LogFile->Lock, TRUE);
InitializeObjectAttributes(&ObjectAttributes,
BackupFileName,
OBJ_CASE_INSENSITIVE,
NULL,
NULL);
Status = NtCreateFile(&BackupLogFile.FileHandle,
GENERIC_READ | GENERIC_WRITE | SYNCHRONIZE,
&ObjectAttributes,
&IoStatusBlock,
NULL,
FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ,
FILE_CREATE,
FILE_WRITE_THROUGH | FILE_SYNCHRONOUS_IO_NONALERT,
NULL,
0);
if (!NT_SUCCESS(Status))
{
DPRINT("Cannot create backup file `%wZ' (Status 0x%08lx)\n", BackupFileName, Status);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
goto Quit;
}
Status = ElfBackupFile(&LogFile->LogFile,
&BackupLogFile.LogFile);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
Quit:
/* Close the backup file */
if (BackupLogFile.FileHandle != NULL)
NtClose(BackupLogFile.FileHandle);
/* Unlock the log file */
RtlReleaseResource(&LogFile->Lock);
return Status;
}
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
static NTSTATUS
ReadRecord(IN PEVTLOGFILE LogFile,
IN ULONG RecordNumber,
OUT PEVENTLOGRECORD Record,
IN SIZE_T BufSize, // Length
OUT PSIZE_T BytesRead OPTIONAL,
OUT PSIZE_T BytesNeeded OPTIONAL,
IN BOOLEAN Ansi)
{
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
NTSTATUS Status;
PEVENTLOGRECORD UnicodeBuffer = NULL;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
PEVENTLOGRECORD Src, Dst;
ANSI_STRING StringA;
UNICODE_STRING StringW;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
PVOID SrcPtr, DstPtr;
DWORD i;
DWORD dwPadding;
DWORD dwRecordLength;
PDWORD pLength;
if (!Ansi)
{
return ElfReadRecord(LogFile,
RecordNumber,
Record,
BufSize,
BytesRead,
BytesNeeded);
}
if (BytesRead)
*BytesRead = 0;
if (BytesNeeded)
*BytesNeeded = 0;
UnicodeBuffer = LogfpAlloc(BufSize, HEAP_ZERO_MEMORY, TAG_ELF_BUF);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
if (UnicodeBuffer == NULL)
{
DPRINT1("Alloc failed!\n");
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
return STATUS_NO_MEMORY;
}
Status = ElfReadRecord(LogFile,
RecordNumber,
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
UnicodeBuffer,
BufSize,
BytesRead,
BytesNeeded);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
if (!NT_SUCCESS(Status))
goto Quit;
Src = UnicodeBuffer;
Dst = Record;
Dst->Reserved = Src->Reserved;
Dst->RecordNumber = Src->RecordNumber;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
Dst->TimeGenerated = Src->TimeGenerated;
Dst->TimeWritten = Src->TimeWritten;
Dst->EventID = Src->EventID;
Dst->EventType = Src->EventType;
Dst->EventCategory = Src->EventCategory;
Dst->NumStrings = Src->NumStrings;
Dst->UserSidLength = Src->UserSidLength;
Dst->DataLength = Src->DataLength;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
SrcPtr = (PVOID)((ULONG_PTR)Src + sizeof(EVENTLOGRECORD));
DstPtr = (PVOID)((ULONG_PTR)Dst + sizeof(EVENTLOGRECORD));
/* Convert the module name */
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
RtlInitUnicodeString(&StringW, SrcPtr);
Status = RtlUnicodeStringToAnsiString(&StringA, &StringW, TRUE);
if (NT_SUCCESS(Status))
{
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
RtlCopyMemory(DstPtr, StringA.Buffer, StringA.MaximumLength);
DstPtr = (PVOID)((ULONG_PTR)DstPtr + StringA.MaximumLength);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
RtlFreeAnsiString(&StringA);
}
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
else
{
RtlZeroMemory(DstPtr, StringW.MaximumLength / sizeof(WCHAR));
DstPtr = (PVOID)((ULONG_PTR)DstPtr + StringW.MaximumLength / sizeof(WCHAR));
}
SrcPtr = (PVOID)((ULONG_PTR)SrcPtr + StringW.MaximumLength);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
/* Convert the computer name */
RtlInitUnicodeString(&StringW, SrcPtr);
Status = RtlUnicodeStringToAnsiString(&StringA, &StringW, TRUE);
if (NT_SUCCESS(Status))
{
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
RtlCopyMemory(DstPtr, StringA.Buffer, StringA.MaximumLength);
DstPtr = (PVOID)((ULONG_PTR)DstPtr + StringA.MaximumLength);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
RtlFreeAnsiString(&StringA);
}
else
{
RtlZeroMemory(DstPtr, StringW.MaximumLength / sizeof(WCHAR));
DstPtr = (PVOID)((ULONG_PTR)DstPtr + StringW.MaximumLength / sizeof(WCHAR));
}
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
/* Add the padding and the User SID */
dwPadding = sizeof(ULONG) - (((ULONG_PTR)DstPtr - (ULONG_PTR)Dst) % sizeof(ULONG));
RtlZeroMemory(DstPtr, dwPadding);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
SrcPtr = (PVOID)((ULONG_PTR)Src + Src->UserSidOffset);
DstPtr = (PVOID)((ULONG_PTR)DstPtr + dwPadding);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
Dst->UserSidOffset = (DWORD)((ULONG_PTR)DstPtr - (ULONG_PTR)Dst);
RtlCopyMemory(DstPtr, SrcPtr, Src->UserSidLength);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
/* Convert the strings */
SrcPtr = (PVOID)((ULONG_PTR)Src + Src->StringOffset);
DstPtr = (PVOID)((ULONG_PTR)DstPtr + Src->UserSidLength);
Dst->StringOffset = (DWORD)((ULONG_PTR)DstPtr - (ULONG_PTR)Dst);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
for (i = 0; i < Dst->NumStrings; i++)
{
RtlInitUnicodeString(&StringW, SrcPtr);
Status = RtlUnicodeStringToAnsiString(&StringA, &StringW, TRUE);
if (NT_SUCCESS(Status))
{
RtlCopyMemory(DstPtr, StringA.Buffer, StringA.MaximumLength);
DstPtr = (PVOID)((ULONG_PTR)DstPtr + StringA.MaximumLength);
RtlFreeAnsiString(&StringA);
}
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
else
{
RtlZeroMemory(DstPtr, StringW.MaximumLength / sizeof(WCHAR));
DstPtr = (PVOID)((ULONG_PTR)DstPtr + StringW.MaximumLength / sizeof(WCHAR));
}
SrcPtr = (PVOID)((ULONG_PTR)SrcPtr + StringW.MaximumLength);
}
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
/* Copy the binary data */
SrcPtr = (PVOID)((ULONG_PTR)Src + Src->DataOffset);
Dst->DataOffset = (ULONG_PTR)DstPtr - (ULONG_PTR)Dst;
RtlCopyMemory(DstPtr, SrcPtr, Src->DataLength);
DstPtr = (PVOID)((ULONG_PTR)DstPtr + Src->DataLength);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
/* Add the padding */
dwPadding = sizeof(ULONG) - (((ULONG_PTR)DstPtr - (ULONG_PTR)Dst) % sizeof(ULONG));
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
RtlZeroMemory(DstPtr, dwPadding);
/* Set the record length at the beginning and the end of the record */
dwRecordLength = (DWORD)((ULONG_PTR)DstPtr + dwPadding + sizeof(ULONG) - (ULONG_PTR)Dst);
Dst->Length = dwRecordLength;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
pLength = (PDWORD)((ULONG_PTR)DstPtr + dwPadding);
*pLength = dwRecordLength;
if (BytesRead)
*BytesRead = dwRecordLength;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
Status = STATUS_SUCCESS;
Quit:
LogfpFree(UnicodeBuffer, 0, TAG_ELF_BUF);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
return Status;
}
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
/*
* NOTE:
* 'RecordNumber' is a pointer to the record number at which the read operation
* should start. If the record number is 0 and the flags given in the 'Flags'
* parameter contain EVENTLOG_SEQUENTIAL_READ, an adequate record number is
* computed.
*/
NTSTATUS
LogfReadEvents(PLOGFILE LogFile,
ULONG Flags,
PULONG RecordNumber,
ULONG BufSize,
PBYTE Buffer,
PULONG BytesRead,
PULONG BytesNeeded,
BOOLEAN Ansi)
{
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
NTSTATUS Status;
ULONG RecNum;
SIZE_T ReadLength, NeededSize;
ULONG BufferUsage;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
/* Parameters validation */
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
/* EVENTLOG_SEQUENTIAL_READ and EVENTLOG_SEEK_READ are mutually exclusive */
if ((Flags & EVENTLOG_SEQUENTIAL_READ) && (Flags & EVENTLOG_SEEK_READ))
return STATUS_INVALID_PARAMETER;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
if (!(Flags & EVENTLOG_SEQUENTIAL_READ) && !(Flags & EVENTLOG_SEEK_READ))
return STATUS_INVALID_PARAMETER;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
/* EVENTLOG_FORWARDS_READ and EVENTLOG_BACKWARDS_READ are mutually exclusive */
if ((Flags & EVENTLOG_FORWARDS_READ) && (Flags & EVENTLOG_BACKWARDS_READ))
return STATUS_INVALID_PARAMETER;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
if (!(Flags & EVENTLOG_FORWARDS_READ) && !(Flags & EVENTLOG_BACKWARDS_READ))
return STATUS_INVALID_PARAMETER;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
if (!Buffer || !BytesRead || !BytesNeeded)
return STATUS_INVALID_PARAMETER;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
/* In seek read mode, a record number of 0 is invalid */
if (!(Flags & EVENTLOG_SEQUENTIAL_READ) && (*RecordNumber == 0))
return STATUS_INVALID_PARAMETER;
/* Lock the log file shared */
RtlAcquireResourceShared(&LogFile->Lock, TRUE);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
/*
* In sequential read mode, a record number of 0 means we need
* to determine where to start the read operation. Otherwise
* we just use the provided record number.
*/
if ((Flags & EVENTLOG_SEQUENTIAL_READ) && (*RecordNumber == 0))
{
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
if (Flags & EVENTLOG_FORWARDS_READ)
{
*RecordNumber = ElfGetOldestRecord(&LogFile->LogFile);
}
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
else // if (Flags & EVENTLOG_BACKWARDS_READ)
{
*RecordNumber = ElfGetCurrentRecord(&LogFile->LogFile) - 1;
}
}
RecNum = *RecordNumber;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
*BytesRead = 0;
*BytesNeeded = 0;
BufferUsage = 0;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
do
{
Status = ReadRecord(&LogFile->LogFile,
RecNum,
(PEVENTLOGRECORD)(Buffer + BufferUsage),
BufSize - BufferUsage,
&ReadLength,
&NeededSize,
Ansi);
if (Status == STATUS_NOT_FOUND)
{
if (BufferUsage == 0)
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
{
Status = STATUS_END_OF_FILE;
goto Quit;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
}
else
{
break;
}
}
else
if (Status == STATUS_BUFFER_TOO_SMALL)
{
if (BufferUsage == 0)
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
{
*BytesNeeded = NeededSize;
// Status = STATUS_BUFFER_TOO_SMALL;
goto Quit;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
}
else
{
break;
}
}
else
if (!NT_SUCCESS(Status))
{
DPRINT1("ElfReadRecord failed (Status 0x%08lx)\n", Status);
goto Quit;
}
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
/* Go to the next event record */
/*
* NOTE: This implicitly supposes that all the other record numbers
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
* are consecutive (and do not jump than more than one unit); but if
* it is not the case, then we would prefer here to call some
* "get_next_record_number" function.
*/
if (Flags & EVENTLOG_FORWARDS_READ)
RecNum++;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
else // if (Flags & EVENTLOG_BACKWARDS_READ)
RecNum--;
BufferUsage += ReadLength;
}
while (BufferUsage <= BufSize);
*BytesRead = BufferUsage;
*RecordNumber = RecNum;
Status = STATUS_SUCCESS;
Quit:
/* Unlock the log file */
RtlReleaseResource(&LogFile->Lock);
if (!NT_SUCCESS(Status))
DPRINT1("LogfReadEvents failed (Status 0x%08lx)\n", Status);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
return Status;
}
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
NTSTATUS
LogfWriteRecord(PLOGFILE LogFile,
PEVENTLOGRECORD Record,
SIZE_T BufSize)
{
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
NTSTATUS Status;
LARGE_INTEGER SystemTime;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
// ASSERT(sizeof(*Record) == sizeof(RecBuf));
if (!Record || BufSize < sizeof(*Record))
return STATUS_INVALID_PARAMETER;
/* Lock the log file exclusive */
RtlAcquireResourceExclusive(&LogFile->Lock, TRUE);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
/*
* Retrieve the record written time now, that will also be compared
* with the existing events timestamps in case the log is wrapping.
*/
NtQuerySystemTime(&SystemTime);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
RtlTimeToSecondsSince1970(&SystemTime, &Record->TimeWritten);
Status = ElfWriteRecord(&LogFile->LogFile, Record, BufSize);
if (Status == STATUS_LOG_FILE_FULL)
{
/* The event log file is full, queue a message box for the user and exit */
// TODO!
DPRINT1("Log file `%S' is full!\n", LogFile->LogName);
}
/* Unlock the log file */
RtlReleaseResource(&LogFile->Lock);
return Status;
}
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
PEVENTLOGRECORD
LogfAllocAndBuildNewRecord(PSIZE_T pRecSize,
ULONG Time,
USHORT wType,
USHORT wCategory,
ULONG dwEventId,
PUNICODE_STRING SourceName,
PUNICODE_STRING ComputerName,
ULONG dwSidLength,
PSID pUserSid,
USHORT wNumStrings,
PWSTR pStrings,
ULONG dwDataSize,
PVOID pRawData)
{
SIZE_T RecSize;
SIZE_T SourceNameSize, ComputerNameSize, StringLen;
PBYTE Buffer;
PEVENTLOGRECORD pRec;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
PWSTR str;
UINT i, pos;
SourceNameSize = (SourceName && SourceName->Buffer) ? SourceName->Length : 0;
ComputerNameSize = (ComputerName && ComputerName->Buffer) ? ComputerName->Length : 0;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
RecSize = sizeof(EVENTLOGRECORD) + /* Add the sizes of the strings, NULL-terminated */
SourceNameSize + ComputerNameSize + 2*sizeof(UNICODE_NULL);
/* Align on DWORD boundary for the SID */
RecSize = ROUND_UP(RecSize, sizeof(ULONG));
RecSize += dwSidLength;
/* Add the sizes for the strings array */
ASSERT((pStrings == NULL && wNumStrings == 0) ||
(pStrings != NULL && wNumStrings >= 0));
for (i = 0, str = pStrings; i < wNumStrings; i++)
{
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
StringLen = wcslen(str) + 1; // str must be != NULL
RecSize += StringLen * sizeof(WCHAR);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
str += StringLen;
}
/* Add the data size */
RecSize += dwDataSize;
/* Align on DWORD boundary for the full structure */
RecSize = ROUND_UP(RecSize, sizeof(ULONG));
/* Size of the trailing 'Length' member */
RecSize += sizeof(ULONG);
Buffer = RtlAllocateHeap(GetProcessHeap(), HEAP_ZERO_MEMORY, RecSize);
if (!Buffer)
{
DPRINT1("Cannot allocate heap!\n");
return NULL;
}
pRec = (PEVENTLOGRECORD)Buffer;
pRec->Length = RecSize;
pRec->Reserved = LOGFILE_SIGNATURE;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
/*
* Do not assign here any precomputed record number to the event record.
* The true record number will be assigned atomically and sequentially in
* LogfWriteRecord, so that all the event records will have consistent and
* unique record numbers.
*/
pRec->RecordNumber = 0;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
/*
* Set the generated time, and temporarily set the written time
* with the generated time.
*/
pRec->TimeGenerated = Time;
pRec->TimeWritten = Time;
pRec->EventID = dwEventId;
pRec->EventType = wType;
pRec->EventCategory = wCategory;
pos = sizeof(EVENTLOGRECORD);
/* NOTE: Equivalents of RtlStringCbCopyUnicodeString calls */
if (SourceNameSize)
{
StringCbCopyNW((PWSTR)(Buffer + pos), SourceNameSize + sizeof(UNICODE_NULL),
SourceName->Buffer, SourceNameSize);
}
pos += SourceNameSize + sizeof(UNICODE_NULL);
if (ComputerNameSize)
{
StringCbCopyNW((PWSTR)(Buffer + pos), ComputerNameSize + sizeof(UNICODE_NULL),
ComputerName->Buffer, ComputerNameSize);
}
pos += ComputerNameSize + sizeof(UNICODE_NULL);
/* Align on DWORD boundary for the SID */
pos = ROUND_UP(pos, sizeof(ULONG));
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
pRec->UserSidLength = 0;
pRec->UserSidOffset = 0;
if (dwSidLength)
{
RtlCopyMemory(Buffer + pos, pUserSid, dwSidLength);
pRec->UserSidLength = dwSidLength;
pRec->UserSidOffset = pos;
pos += dwSidLength;
}
pRec->StringOffset = pos;
for (i = 0, str = pStrings; i < wNumStrings; i++)
{
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
StringLen = wcslen(str) + 1; // str must be != NULL
StringCchCopyW((PWSTR)(Buffer + pos), StringLen, str);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
str += StringLen;
pos += StringLen * sizeof(WCHAR);
}
pRec->NumStrings = wNumStrings;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
pRec->DataLength = 0;
pRec->DataOffset = 0;
if (dwDataSize)
{
RtlCopyMemory(Buffer + pos, pRawData, dwDataSize);
pRec->DataLength = dwDataSize;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
pRec->DataOffset = pos;
pos += dwDataSize;
}
/* Align on DWORD boundary for the full structure */
pos = ROUND_UP(pos, sizeof(ULONG));
/* Initialize the trailing 'Length' member */
*((PDWORD)(Buffer + pos)) = RecSize;
*pRecSize = RecSize;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
return pRec;
}
VOID
LogfReportEvent(USHORT wType,
USHORT wCategory,
ULONG dwEventId,
USHORT wNumStrings,
PWSTR pStrings,
ULONG dwDataSize,
PVOID pRawData)
{
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
NTSTATUS Status;
UNICODE_STRING SourceName, ComputerName;
PEVENTLOGRECORD LogBuffer;
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
LARGE_INTEGER SystemTime;
ULONG Time;
SIZE_T RecSize;
DWORD dwComputerNameLength;
WCHAR szComputerName[MAX_COMPUTERNAME_LENGTH + 1];
if (!EventLogSource)
return;
RtlInitUnicodeString(&SourceName, EventLogSource->szName);
dwComputerNameLength = ARRAYSIZE(szComputerName);
if (!GetComputerNameW(szComputerName, &dwComputerNameLength))
szComputerName[0] = L'\0';
RtlInitUnicodeString(&ComputerName, szComputerName);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
NtQuerySystemTime(&SystemTime);
RtlTimeToSecondsSince1970(&SystemTime, &Time);
LogBuffer = LogfAllocAndBuildNewRecord(&RecSize,
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
Time,
wType,
wCategory,
dwEventId,
&SourceName,
&ComputerName,
0,
NULL,
wNumStrings,
pStrings,
dwDataSize,
pRawData);
if (LogBuffer == NULL)
{
DPRINT1("LogfAllocAndBuildNewRecord failed!\n");
return;
}
Status = LogfWriteRecord(EventLogSource->LogFile, LogBuffer, RecSize);
[EVENTLOG] - Get rid of MyHeap. - Continue using safe string functions. - Allow event logs themselves to be their own source. And store the full list of log sources in the "Sources" registry multi-string value. - Correctly compute the number of records. - Correctly return the event number and the write timestamp of reported events. - Use a helper function for ElfrReportEventW/A and for ElfrReportEventAndSourceW that is now implemented. - Rewrite the file.c functions using NT-APIs almost exclusively for file operations. - Modify the logic of LogfReadEvents so that a RecordNumber == 0 in sequential read mode means we need to determine where to start the read operation, depending on whether a forwards-read or a backwards-read is performed. The log handle's CurrentRecord member is therefore initialized to 0 before usage. - Adjust LogfAllocAndBuildNewRecord to take in input the event generation timestamp. - Do not "compute" the RecordNumber of the new event in LogfAllocAndBuildNewRecord; it will be consistently assigned by LogfWriteRecord. - Correctly initialize the OldestRecordNumber to zero for new (empty) logs. - Perform extensive log validity checks when opening existing logs: log header and EOF record as well as boundary checks. - Rewrite almost of the functions to support event log wrapping (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb309026(v=vs.85).aspx ) and splitted records. Now our event logs are not corrupted anymore, and are readable under Windows 2k/xp/2k3/Vista+. - As a consequence of supporting wrapping event logs we need to iterate through them at loading time in order to locate the valid EOF record (indeed it may happen that the log header is not correctly synced, and its Start/EndOffsets are invalid. The EOF record offsets contain on the other way the correct values). The file.c fixes are a bit still work-in-progress, but the bulk of the code works. It is extensively tested in situ in my local VM since 2 months now. CORE-11843 #resolve svn path=/trunk/; revision=72236
2016-08-16 21:08:15 +00:00
if (!NT_SUCCESS(Status))
{
DPRINT1("ERROR writing to event log `%S' (Status 0x%08lx)\n",
EventLogSource->LogFile->LogName, Status);
}
LogfFreeRecord(LogBuffer);
}