I find it surprising and shocking that Rockstar would actually recommend disabling the Event Log. It’s not just some extraneous service that most people don’t use, it’s a required service that Windows expects to be running, and frankly I would be surprised if you don’t get a crash at some point if it is disabled. (It’s like trying to run Windows with the RPC service disabled: you might be able to do it for a bit, but expect a BSOD soon.)
Besides, the Event Log does not normally cause any sort of performance problem whatsoever (it is normally idle unless a relevant event has been generated), so if GTA IV actually gets bogged down when it’s running, then the problem is either due to a bad audio or video driver, in which case you should update it to alleviate the problem, or else the issue is that the game has a bug that is causing many (read thousands of events per seconds) to get written to the log. In that case, they should fix the bug rather than recommend users compromise the integrity of their systems to accommodate their sloppy programming.
From the FAQ, it sounds like either GTA IV is not compatible with Win64 (in which case it is incumbent on Rockstar to fix—and I would be surprised if they couldn’t since they updated GTA 1 and 2 to run well on XP), or else it is an input driver or software that is causing something to be displayed on screen whenever you press a key (eg an OSD, hence the flashes). See if there is an updated keyboard driver available or check your keyboard manufacturer’s FAQs or forums for mentions of this issue. Also see if there is some sort of keyboard program (eg MS Intellipoint, Logitech iTouch) running and either quit it or disable the OSD.
You can filter by EventID to see specific types of events. There are many Windows Installer Event IDs corresponding to different sorts of actions. 1033 indicates a product was installed, 1034 indicates a product was uninstalled.
For Windows Installer you can also filter by Source. MsiInstaller is the source for all Windows Installer events.
InstallShield tends to be a wrapper for MSI scripts, so it would generally have the same event IDs. However, other installer packages will generally not use the same EventIDs. For any installer you'll need to find the appropriate event ids it uses (if any).
UPDATE details:
Oh, and those are all found in the event viewer under Application.
UPDATE response:
The Windows Event IDs do not change from OS to OS as these are determined by the application. In this case, Windows Installer.
I tested on my XP box and a 2003 server and they both used 1033 for install and 1034 for uninstall.
You may try installing a windows update patch or similar. Something small, like a root certificate update or the like. Then check the event logs for corresponding entries. This will allow you to see if the logs have been cleared since the last install.
UPDATE further details, alternate IDs:
There is a plethora of information online regarding event IDs, including lists of all possible EventIDs for MSI Installers. Looking briefly I'm not really sure what the difference is between 1033/1034 and 11707/11708 IDs. MS documentation seems to show that the two different types indicate the same thing, namely the successful install or uninstall, but contain different sorts of information.
Best Answer
First of all - it might not be anybody accessing your eventlogs remotely. Eventlog files are always open. They are memory-mapped files, so you can't just delete them from the disk.
If you need the disk space, you need to open eventvwr.msc and alter the maximum size of the log file there. The change won't take effect until the next restart of the eventlog service (which will probably be when you reboot the machine).
If you want to clear the logs (ie remove the data), you can also do this in the eventvwr mmc snap-in.
If you have a need to keep eventlogs in a deletable file, you can use the AutoBackupLogFiles registry key, but the memory-mapped files will still remain.
If you still suspect that a user account is accessing the eventlog on your computer remotely, and this includes the security log - you should check the security log for events with ID 4672, and look for accounts logging on with SeSecurityPrivilege enabled.
If you don't think the security log is the one being accessed, you can still look for events in the security log with ID 4624, which should show you who has been accessing the computer remotely (but will include all users, not just the one/ones accessing the eventlogs). This should at least narrow your list of suspects.
You could always use wevtutil to add an audit SACL to the logs which you think are being accessed. The process is much the same as for adding permissions (DACL), except you're saying which things should be audited, as opposed to allowed or denied.
Slightly less elegant, but when you notice a connection from the remote IP, you can try running qwinsta /server:remoteIP. This will show you who is logged on at that computer, either locally at the console or via terminal services. It won't help if the "user" is a service account or a scheduled task.