Another consultant emailed me a .evt file recently for review. Which is great, except I frequently go days now without sitting in front of a Windows workstation – or at least, not one that isn’t broken and in need of fixing. So, I needed to find a Windows Event Log viewer.
There isn’t currently one in the Debian or Ubuntu repositories, but I did find a free-as-in-beer tool at TZWorks, LLC which did the trick nicely. It’s currently available for download in Windows, Linux (i386), and Mac versions – I haven’t tested the Mac version, but the Windows and Linux versions both run fine and do the job well, both for the older .evt and the newer .evtx (Vista and up) formats.
Note: the Linux binary provided is currently 32-bit only, so if you’re running a 64-bit system you’ll either need to install ia32-libs (apt-get install ia32-libs on Debian or Ubuntu), or just run the Windows version under WINE.
EDIT, September 2014: you can’t tell from looking at the download page, but this app now costs $228 for a single copy of it. So, uh, keep moving if you want a reasonable tool to look at Event Viewer logs with, sorry. >=\
In today’s battle with malware, I learned a couple of interesting new places in the registry to check:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
Place a key in here named after the file you want to prevent running, then place a STRING value under the key named “debugger”. Now, set the value of “debugger” to cmd, or some other relatively harmless executable that ignores its standard input – and presto, the application matching the keyname won’t run. BAD MALWARE. NO COOKIE.
Ironically, this is also quite useful for the GOOD guys keeping relatively clueless but persistent users from running things they really shouldn’t, like notorious P2P clients. For extra points, create a file C:\null.cmd or similar that simply exits, and use that as the “debugger” – they don’t even see anything happening at all, it just “doesn’t work”. This will probably frustrate them enough to desist, at least for a while… particularly given how used they probably are to the machine not working, if they’re that persistently malwaring it up in the first place.
Place a STRING value in here, and ditto above. (This is where GPO disallowing particular mutexes (I think it’s by mutex, not filename) to run takes effect.)
The More You Know…
The problem is almost certainly that its local cache is corrupt… which happens disturbingly frequently. The easiest way to fix it is to simply close Outlook, delete the local cache, then start Outlook again – the good news being that it works and your new mail starts showing up; the bad news being, of course, that it starts synchronizing /everything/ again.
Stick this command in a batch file, and you’ll have something that users can simply double-click to fix the issue. Just remember to tell them to CLOSE OUTLOOK FIRST! =)
del "%UserProfile%\Local Settings\Application Data\Microsoft\Outlook\*IMAP*-0*.pst"
Had a client whose login to the domain took upwards of 40 seconds on his Windows 7 machine.Â Oddly, completely deleting the profile from his workstation didn’t fix the issue – even after setting up the profile anew after first domain login, it still took upwards of 40 seconds.Â Just as oddly, other profiles on the domain didn’t have the same issue on his workstation – they logged in in less than 10 seconds.
Never did figure out what caused it, but I did find a cure –
- Run gpedit.msc.
- Go to computer configuration.
- Go to Administrative templates.
- Go to System.
- Go to User profiles.
- Enable â€œSet maximum wait time for the network if a user has a roaming user profile or remote home directoryâ€ and set to 0 seconds
Problem solved; the user could now logon in less than ten seconds.