Community
Participate
Working Groups
The EventLogReader.exe program used for converting Windows Event logs to a text file does not convert an LsaSrv event message from the System log correctly on an EM64T machine running Windows 2003 Server Standard x64 Edition SP1. For example, the Description of the LsaSrv event (EventID: 00001791) shown in the Windows Event Viewer is An anonymous session connected from 9.22.33.44 has attempted to open an LSA policy handle on this machine. The attempt was rejected with STATUS_ACCESS_DENIED to prevent leaking security sensitive information to the anonymous caller. The application that made this attempt needs to be fixed. Please contact the application vendor. As a temporary workaround, this security measure can be disabled by setting the \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\TurnOffAnonymousBlock DWORD value to 1. This message will be logged at most once a day. But the message field in the resulting error.log file output from EventLogReader.exe is: Message: 9.22.33.44 ; Note, the full message is included in error.log when running on an IA32 machine with Windows 2003 Server Standard Edition SP1
Deferring this to 4.4 because it is not a stop ship issue for 4.3.
Added sizing.
Targetting to fix in i3 and increasing priority to indicate it is planned for 4.4. Reassigning to Cindy.
Created attachment 65663 [details] logs for dlls which are failed to load It is because that some 64bit dlls are failed to load on 32bit application. The attached file is the dlls which can't be load successfully for system logs on EM64T platform. If the EventLogReader is built as 64bit application. The problem can be solved.
The fix for this requires building a 64-bit version of EventLogReader.exe and using it for parsing Windows event log files on 64-bit Windows systems. Build and packaging changes cannot be accomodated at this stage of the 4.4 release. Deferring to future and this problem will be added to the 4.4 Release Notes.
This is required from AC perspective
The fix for this problem requires the following: 1) A new version of the converter program (eventlogreader3.exe) built as a 64-bit application. This requires adding it to the 64-bit native build that is currently building the 64-bit Windows Agent Controller and ensuring the resulting executable is included in all of the required packages (org.eclipse.hyades.logging.parsers plugin and stand-alone GLA). This problem was found on Windows running on EM64T h/w. It needs to be determined whether this problem also exists on IPF h/w and if so whether an IPF built executable is required to run on IPF machines. 2) Add new sub-directories under config/Windows/(application|security|system) for the adapters that use the 64-bit converter. For these adapters we can try using one copy of the converter program stored in a higher directory as requested in bugzilla 199043. 3) Add new version to logParser extensions for the Windows Event Log parsers (eg. Windows 64-bit) 4) Add code to org.eclipse.hyades.logging.parsers.importer.ParserWrapper.modifyConverter method to handle case of new 64-bit converter program.
Rohit for thise defect you would need to work with the build team to get the 64-bit EventLogReader.exe build.
Targetting 4.5 i2. Resizing to 16h.
Changing target to 4.5 i4.
Joel, Adding you to cc as this defect involves build changes: A new version of the converter program (eventlogreader3.exe) built as a 64-bit application. This requires adding it to the 64-bit native build that is currently building the 64-bit Windows Agent Controller and ensuring the resulting executable is included in all of the required packages (org.eclipse.hyades.logging.parsers plugin and stand-alone GLA).
Targetting to i5, couldn't be contained in i4.
Reassigning to i6.
Fixed, updated sizing to reflect actual work.
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this originator of this enhancement/defect has an inactive Bugzilla account and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since the originator of this enhancement/defect has an inactive Bugzilla account and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
