Windows event log viewer



  • I already hated the newer event log viewer in Windows 7 (vista?), it's a bloated sack that drives me crazy every time I need to use it. Today I finally got pissed off because it takes all day to load up 20k events so I decided to edit the max log size so it would only take half a day. The default is 20MB so I try setting the System Log to 1024KB and it gives me an error that the minimum size is 1028KB, so I click ok and apply that. With my newly acquired knowledge that the minimum is 1028KB, I attempt to set the Application Log to 1028KB and I get this error:

    The Maximum Log Size specified is not valid. It is too large, too small, or not a multiple of 64KB. The Maximum Log Size will be set to the following: 1028KB

    Confused, I look at my entry and it had changed it to 1024KB. I click OK to the error and it changes it to 1028KB. I thought maybe I had just typed in 1024 again on accident so I changed it to 2048, applied and then 1028 again and watched it switch it to 1024 on apply and then to 1028 on ok'ing the error.



  • Microsoft really could have done a better job with the Windows Event Logger.   It has so much potential to be a very useful tool for programs and people to use, but it is things like this that kill it.  On two of my previous programs we had our services write logs out to the event log so we could track how well they were doing and any issues that they were encountering, and it worked very well.  But things like hitting max log sizes, slow performance, and bugs really remove the desire for developers to utilize it.



  • @Anketam said:

    Microsoft really could have done a better job with the Windows Event Logger.

    That's an understatement. They turned something really basic, but usable, into something full of features-- that's virtually impossible to use. Microsoft really put the 'B' squad in charge of that thing.



  • The event viewer sucks shit off a dead donkey balls.

     



  • @alegr said:

    The event viewer sucks shit off a dead donkey balls.

     

     

    Now that is a pleasant mental picture indeed.

     



  • In this case, I fullheartedly agree with Blakeyrat.  Funny part is that they only rewrote a wrapper around the existing Windows Event Viewer.  Same thing only 5 extra mouse clicks to get to it.



  • @error_NoError said:

    The Maximum Log Size specified is not valid. It is too large, too small, or not a multiple of 64KB. The Maximum Log Size will be set to the following: 1028KB
    So, according to Microsoft Math(tm), 1028 is a multiple of 64?



  • @Anonymouse said:

    @error_NoError said:

    The Maximum Log Size specified is not valid. It is too large, too small, or not a multiple of 64KB. The Maximum Log Size will be set to the following: 1028KB
    So, according to Microsoft Math(tm), 1028 is a multiple of 64?

     

    Must be, you can't explain it away as a typo. On no keyboard I know of the 8 is next to the 4.

    Or perhaps I'm being a PD, after all something similar has happened before:

    http://bash.org/?5300

     



  • @erikal said:

    Must be, you can't explain it away as a typo. On no keyboard I know of the 8 is next to the 4.
    Is this close enough for you?:





  • Regardless of your feelings on Dvorak, I actually made a D: face when I saw that number row- I can't see how anyone thought that was a good idea.



  •  @PJH said:

    @erikal said:
    Must be, you can't explain it away as a typo. On no keyboard I know of the 8 is next to the 4.
    Is this close enough for you?:



     

    Yeah. I think while I continue to retain my sanity while visiting this forum, I have to get used to standing corrected. Although I still speak the truth: I didn't actually know about such a keyboard :)



  • @orange_robot said:

    I actually made a D: face when I saw that number row- I can't see how anyone thought that was a good idea.
    Judging from the wiki article linked to the pic, while not explicitly stated, it's supposedly as a result of Benford's Law.



  • @PJH said:

    Judging from the wiki article linked to the pic, while not explicitly stated, it's supposedly as a result of Benford's Law.
     

    Very cool.

    Ok, now everybody fire up Treesize or similar and run the numbers for file sizes on your hard drive.



  • @dhromed said:

    Ok, now everybody fire up Treesize or similar and run the numbers for file sizes on your hard drive.
    I would have thought running it against source code would give a better representation of what's required - I'd expect Benford's law to hold against file sizes (presuming you're treating the file size as a single number,) since the Law states that the distribution evens out as you go further right along the number to the units, but I'm not entirely convinced about actually typing, where the placement doesn't matter, and each occurrence of a number should be treated as 'the first number' for the purposes of deciding frequency of numbers.




    I'd expect 0 to happen a lot more often that Benford would suggest for example.



  • @PJH said:

    @orange_robot said:
    I actually made a D: face when I saw that number row- I can't see how anyone thought that was a good idea.
    Judging from the wiki article linked to the pic, while not explicitly stated, it's supposedly as a result of Benford's Law.

    That doesn't even make sense.. who cares about the first number? I have to type all of the numbers in, why does the first matter?



  • @morbiuswilters said:

    That doesn't even make sense.. who cares about the first number? I have to type all of the numbers in, why does the first matter?

    The theory is that more numbers (in the set of all possible numbers) contain 1 than numbers that contain 8, so at least in theory you're typing 1 several times more often than you're typing 8, so 1 should be easier-to-hit than 8.

    Whether that theory applies in practice or not when it comes to keyboards, I have no idea. Why anybody interested in fast entry of numbers would use the bar at the top of the keyboard instead of the numeric keypad, I also have no idea.



  • @blakeyrat said:

    @morbiuswilters said:
    That doesn't even make sense.. who cares about the first number? I have to type all of the numbers in, why does the first matter?

    The theory is that more numbers (in the set of all possible numbers) contain 1 than numbers that contain 8, so at least in theory you're typing 1 several times more often than you're typing 8, so 1 should be easier-to-hit than 8.

    Whether that theory applies in practice or not when it comes to keyboards, I have no idea. Why anybody interested in fast entry of numbers would use the bar at the top of the keyboard instead of the numeric keypad, I also have no idea.

    Benford's Law applies to first digits, not all digits (there may be some other law concerning all digits, I dunno). Here's what this feature does:

    Boss: I need you to type in all the digits of pi!

    Lackey: I better re-arrange my keyboard so the 3 is easy to hit, because that's the first number!



  • @morbiuswilters said:

    Benford's Law applies to first digits, not all digits (there may be some other law concerning all digits, I dunno). Here's what this feature does:

    Boss: I need you to type in all the digits of pi!

    Lackey: I better re-arrange my keyboard so the 3 is easy to hit, because that's the first number!

    I see what you're saying, but in the real world people aren't typing Pi, they're typing 3-, 4-, 5-digit numbers. Moving away from Benford's law would only make sense (I believe? Maybe my logic is wrong here...) if people are regularly typing numbers of 10+ digits. Which doesn't happen often.



  • @PJH said:

    @erikal said:
    Must be, you can't explain it away as a typo. On no keyboard I know of the 8 is next to the 4.
    Is this close enough for you?:



    You had to bring up Dvorak keyboards? Do you not have a numpad on your keyboard?



  • Now I know!

    Yes, as you get into the deep 10-digit number range, the usage of "1" hovers right around 10%, as you'd expect. For lower numbers, however, Benford's Law does apply.



  • Benford's law more applies in cases like: the IRS checking your return and flagging suspicious returns for an audit if the numbers don't follow the correct distribution.



  • @blakeyrat said:

    @morbiuswilters said:
    Benford's Law applies to first digits, not all digits (there may be some other law concerning all digits, I dunno). Here's what this feature does:

    Boss: I need you to type in all the digits of pi!

    Lackey: I better re-arrange my keyboard so the 3 is easy to hit, because that's the first number!

    I see what you're saying, but in the real world people aren't typing Pi, they're typing 3-, 4-, 5-digit numbers. Moving away from Benford's law would only make sense (I believe? Maybe my logic is wrong here...) if people are regularly typing numbers of 10+ digits. Which doesn't happen often.

    Ah, I think I'm kind of understanding. For a 3-to-5-digit number, the first digit has a large impact on the total distribution of digits. So with a 3-digit number, that distribution of 1s will be higher simply because the first digit accounts for 1/3rd of the whole. So for 3-to-5-digit numbers you actually are typing 1 more often than other numbers (although the distribution is nowhere near as uneven as it is for first digits), hence it makes a very tiny amount of sense to arrange the keyboard accordingly.



  • @morbiuswilters said:

    Ah, I think I'm kind of understanding. For a 3-to-5-digit number, the first digit has a large impact on the total distribution of digits. So with a 3-digit number, that distribution of 1s will be higher simply because the first digit accounts for 1/3rd of the whole. So for 3-to-5-digit numbers you actually are typing 1 more often than other numbers (although the distribution is nowhere near as uneven as it is for first digits), hence it makes a very tiny amount of sense to arrange the keyboard accordingly.

    Yeah, that's what I was hitting at.

    Of course it would make 50 times more sense to just trash the top row of numbers and ensure every keyboard has a numeric keypad. But then Dvorak was designing for typewriters, not computers.



  • @blakeyrat said:

    @morbiuswilters said:
    Ah, I think I'm kind of understanding. For a 3-to-5-digit number, the first digit has a large impact on the total distribution of digits. So with a 3-digit number, that distribution of 1s will be higher simply because the first digit accounts for 1/3rd of the whole. So for 3-to-5-digit numbers you actually are typing 1 more often than other numbers (although the distribution is nowhere near as uneven as it is for first digits), hence it makes a very tiny amount of sense to arrange the keyboard accordingly.

    Yeah, that's what I was hitting at.

    Of course it would make 50 times more sense to just trash the top row of numbers and ensure every keyboard has a numeric keypad. But then Dvorak was designing for typewriters, not computers.

    Well, top row numbers are useful for laptops. And I never use the numpad, really. I'm only typing short sequences of digits, so it's easier to just hit the top row rather than move my hand.



  • I wrote some bullshit graph. The numbers are from all the a-z characters on this page – since before this post.

    It kind of works, I guess.



  • @blakeyrat said:

    see what you're saying, but in the real world people aren't typing Pi, they're typing 3-, 4-, 5-digit numbers.
     

    I wonder if Benford's law will hold if you take chunks from a transcendental number (such as pi).

    Instead of writing a crummy script, I'm going to play some games.



  • @blakeyrat said:

    Now I know!

    Yes, as you get into the deep 10-digit number range, the usage of "1" hovers right around 10%, as you'd expect. For lower numbers, however, Benford's Law does apply.

     

    You're randomly generating numbers? Benfor's law only applies to natural sets. If you generate randomly, then sure, everything's going to even out at 10%.

     



  • @dhromed said:

    I wonder if Benford's law will hold if you take chunks from a transcendental number (such as pi).

    No. It only applies to the first digit. It doesn't matter if the number is 1 digit long or if it is transcendental.



  • @morbiuswilters said:

    And I never use the numpad, really. I'm only typing short sequences of digits,
     

    Never got that 4+ digit paycheck, did you?



  • @morbiuswilters said:

    @dhromed said:
    I wonder if Benford's law will hold if you take chunks from a transcendental number (such as pi).

    No. It only applies to the first digit. It doesn't matter if the number is 1 digit long or if it is transcendental.

     

    I mean if you calculate pi to some arbitrary length, and randomly chunk it, then take the first digit of each chunk. The naturalness of pi will probably negate the randomness of the chunk length.

    I am probably spouting complete nonsense, negating the randomness of my point.

    Edit.

    Or rather, chunk it with exponentially increasing chunk length.

    Edit II

    Eh, still nonsense, probably.



  • @dhromed said:

    You're randomly generating numbers?

    Nope, just counting up sequentially.

    I considered adding a "modifier for popularity", i.e. 2 digit numbers are 5 times more popular than 3-digit numbers which are 5 times more popular than 4 digit numbers, etc. But I didn't know what the proportions were in real-world data so I didn't.

    So it just counts from zero, and counts the digits in each number.

    Source code or something.



  • @blakeyrat said:

    So it just counts from zero
     

    Try an exponential growth function.

    counts the digits in each number.

    Wait, your program counts the number's length in digits, or counts the occurrences of each first digit? Because of you just count up, then nothing's going to happen either way.



  • @dhromed said:

    @morbiuswilters said:

    And I never use the numpad, really. I'm only typing short sequences of digits,
     

    Never got that 4+ digit paycheck, did you?

    Well, I'm never typing my paycheck into my computer, so my point stands. I did get a 5 digit paycheck once, but it turned out to be a clerical error and I had to give most of it back.



  • @dhromed said:

    counts the digits in each number.

    Wait, your program counts the number's length in digits, or counts the occurrences of each first digit? Because of you just count up, then nothing's going to happen either way.

    I linked to the fucking code. Read the fucking code. Don't be helpless.

    Current number: 5301147692
    0	4731815921	9.11711477798382%
    1	5840874724	11.2540145583851%
    2	5840679339	11.253638096684%
    3	5741827031	11.0631725643913%
    4	5740677031	11.0609567803942%
    5	5041817031	9.71441521155079%
    6	4740669331	9.13417325119879%
    7	4740668931	9.13417248049131%
    8	4740668239	9.13417114716738%
    9	4740668231	9.13417113175323%
    


  • @blakeyrat said:

    I linked to the fucking code. Read the fucking code. Don't be helpless.

    Oh shit, Blakeyrat open sourced some of his code and now he's become a stereotypical Open Sores developer!!!



  • @blakeyrat said:

    I linked to the fucking code. Read the fucking code. Don't be helpless.
     

    I just read the fucking code anf it fucking looks like it's fucking doing the right fucking thing but I didn't fucking investigate fucking further, but I do fucking know that you fucking should not just fucking add 1 for every fucking iteration because that's fucking not going to fucking work.



  •  @morbiuswilters said:

    @blakeyrat said:
    I linked to the fucking code. Read the fucking code. Don't be helpless.

    Oh shit, Blakeyrat open sourced some of his code and now he's become a stereotypical Open Sores developer!!!

    I was planning on responding to comments on my code such as "That code is complete shit." with a mirthful "That's because I made it open source. It was fine when I wrote it!"



  • @dhromed said:

    I just read the fucking code anf it fucking looks like it's fucking doing the right fucking thing but I didn't fucking investigate fucking further, but I do fucking know that you fucking should not just fucking add 1 for every fucking iteration because that's fucking not going to fucking work.

    I don't understand what you're trying to say.

    Current number: 9288350335
    0	8320969398	9.06696359873671%
    1	9432080174	10.2776880321876%
    2	9420430509	10.2649939477078%
    3	9332030439	10.1686686064551%
    4	9331980064	10.1686137152195%
    5	9331970398	10.1686031826402%
    6	9331970063	10.1686028176067%
    7	9331970063	10.1686028176067%
    8	9329670733	10.1660973473406%
    9	8609320398	9.38116593449914%
    


  • Blakey: I don't get WTF you're doing.
    If you're just counting sequentially up to a certain number, you can simply calculate the percentage of that without a computer: How many of the numbers from 0 to 999 start with a 1? Answer is obviously 111. The described distribution comes from the numbers being distributed by a power law, not uniformly.

     

    @dhromed said:

    I mean if you calculate pi to some
    arbitrary length, and randomly chunk it, then take the first digit of
    each chunk. The naturalness of pi will probably negate the randomness of
    the chunk length.

    I am probably spouting complete nonsense, negating the randomness of my point.

    Edit.

    Or rather, chunk it with exponentially increasing chunk length.

    Edit II

    Eh, still nonsense, probably.


    Yes, nonsense. Pi is assumed (though not conclusively proven) to be normal, i.e. the digits are distributed uniformly.

     



  • @PJH said:

    @erikal said:
    Must be, you can't explain it away as a typo. On no keyboard I know of the 8 is next to the 4.
    Is this close enough for you?:





    IAmActually using this keyboard layout. AMA.

    Another peculiarity: the num pad is reordered 123-456-789 instead of 789-456-123 and can type hexadecimal numbers (A to F is shift+1 to 6) as well as parentheses, the letter x (for hex constants) and some more characters ($,;=:). The European version of the keyboard uses the extra key next to shift as a compose key for intuitive access to foreign characters like é, ë or ß, and even exotic characters like İ, ő and þ. Greek letters are also easy to type.



  • @dhromed said:

    I was planning on responding to comments on my code such as "That code is complete shit." with a mirthful "That's because I made it open source. It was fine when I wrote it!"

    Comments would be useful.

    In the code, that is...



  • @topspin said:

    Yes, nonsense. Pi is assumed (though not conclusively proven) to be normal, i.e. the digits are distributed uniformly.
     

    I see.



  • @Anonymouse said:

    @error_NoError said:

    The Maximum Log Size specified is not valid. It is too large, too small, or not a multiple of 64KB. The Maximum Log Size will be set to the following: 1028KB
    So, according to Microsoft Math(tm), 1028 is a multiple of 64?

    Not necessarily.  They may have meant something like the following:

    The Maximum Log Size specified is not valid. It is too large, too small, or not a multiple of 64KB. If it's set to a value which is not a multiple of 64KB, every time the log fills, a chunk of the log file equal to the Maximum Log Size mod 64KB will be corrupted.  This will continue until the entire log file is corrupted.  After that, every time the log fills, a chunk of that size will be rendered usable again.  Once the whole file is once again uncorrupted, the cycle will repeat.  You have set it to such a value.  ENJOY!

    Of course, substituting the real bug description for mine.  I just came up with something entertaining.  I haven't looked at the Windows Event Viewer since discovering that it was a nice concept, but a shame they didn't generate all of the events that one might want, and didn't include key details about some of the events.  That was over a decade ago, so 1. I can't provide further details, 2. They've probably fixed my actual issue from that time, 3. There's probably more issues of the sort I had that they've since coded, some of which have also been fixed.  I am, after all, not a Windows admin.

    (Sadly, I've used software which detected configuration errors, complained about them, but accepted them and used the broken values.  My 'favorite' such application also did a configuration check when one opened the configuration dialog, and would abort if the configuration was currently broken.  So if you closed the configuration dialog after applying a broken configuration (such as if you had hit 'Ok', rather than 'Apply'), the only three fixes were manually editing the configuration file (with a hex editor), restoring the configuration file from a backup, and uninstalling and reinstalling the software.  Fortunately, this happened before the application was updated to use the Registry.)



  • This thread inspired me to go look up the event viewer. I don't know much about it never having done much admin/IT work but it looks like amdkmdag is one hell of an event spammer. Over 90% of my events are from that one service, all of remarking that I don't have a HDCP display connected because I have the nerve to use a VGA monitor. It is crapping these messages out non-stop. WHO THE HELL LET THIS THROUGH QA



  • @nexekho said:

    This thread inspired me to go look up the event viewer. I don't know much about it never having done much admin/IT work but it looks like amdkmdag is one hell of an event spammer. Over 90% of my events are from that one service, all of remarking that I don't have a HDCP display connected because I have the nerve to use a VGA monitor. It is crapping these messages out non-stop. WHO THE HELL LET THIS THROUGH QA

    Oh, still?  Last I looked at the event viewer, it was crapping out similar messages because I had the nerve to use something or other that wasn't the latest and greatest that the computer supported.  However, a friend of mine assured me, if I had the latest and greatest, it'd be crapping out messages about not having the old crap.

    That's the flipside reason why event viewer is suboptimal, but I didn't feel like griping about it.  Logging *something* is better than logging nothing, IMHO.  Until, of course, your disk fills; then you're logging nothing regardless.

    Back in the '90s, my unix syslog had this feature, if something logged the same message to it multiple times in a row, it wouldn't log the second instance.  Instead, it would simply count them, and then when someone *finally* logged something different, it would log a line with the timestamp of the last repeated message (more often than not, the current timestamp - but if you made the chatterbox stop, it could potentially be minutes earlier) saying "last line repeated $count times".  That was over a decade ago.  Why doesn't Microsoft have something like that?

    (Note: I understand where the counting concept fails when you have a centralized loghost.  But as long as you're smart enough to compare hostnames, it's much less of a problem than the repeated log lines.  Also, my current unix system does something more sophisticated - but I'd rather not get into that here, because it's a bit complicated.  I'm only mentioning it, because it doesn't have the same multi-host confusion issue.  It skips that by logging the repeated line a second time, right before the count, but there's more to it.)



  • @tgape said:

    Back in the '90s, my unix syslog had this feature, if something logged the same message to it multiple times in a row, it wouldn't log the second instance.  Instead, it would simply count them, and then when someone finally logged something different, it would log a line with the timestamp of the last repeated message (more often than not, the current timestamp - but if you made the chatterbox stop, it could potentially be minutes earlier) saying "last line repeated $count times".  That was over a decade ago.  Why doesn't Microsoft have something like that?

    The *nix method is to alter verbosity at service or syslog level, so that the file contains just the messages at the required level of detail. Microsoft's method is to log it all[1] then use the filters in the event viewer to alter the level of detail at exposure level, rather than at capture level. AFAIK, there is some quota control and automatic truncating to prevent files growing out of control.

    I don't know which is a more effective method - Microsoft's allows you to drill down more deeply if the required level isn't displayed, which requires a change and rehash of syslog under *nix. I've always followed the "capture everything then turn down noise as you go" rule of thumb from the *nix world, and used logwatch to throw anything interestng over email. Both have their pros/cons.

    [1] again, I'm not a win sysadmin/dba/etc so I don't know if the level of logging to the event viewer is customisable.



  • @morbiuswilters said:

    @dhromed said:
    I wonder if Benford's law will hold if you take chunks from a transcendental number (such as pi).

    No. It only applies to the first digit. It doesn't matter if the number is 1 digit long or if it is transcendental.

    Actually it applies to all digits of any number that is potentially a "counting sequence", transcendentals are not.

    To make is clear... Consider if the numbers are constrain to be between 1 and 199. The first digit will clearly be a 1 more than anything else (actually everything else combined)... But now look if the constraint is between 1 and 219. For numbers where the first digit is two, we have eliminated all used of 2 thru9 in the second digit, therefore increasing the probability of there being a 1 in the second digit across the board..The same logic can be extended for any number of digits.

    Now in the general case the (upper) bounds of the number is not known, therefore one calculates the percentages for every possible upper limit and uses the average. Since there are no upper limits where the probability of a higher digit will exceed (it may equal) that of a lower digit, and since there are limits where the probability of a lower digit, in any position, will be higher, the generalization holds.



  • @TheCPUWizard said:

    @morbiuswilters said:

    @dhromed said:
    I wonder if Benford's law will hold if you take chunks from a transcendental number (such as pi).
    No. It only applies to the first digit. It doesn't matter if the number is 1 digit long or if it is transcendental.

    Actually it applies to all digits of any number that is potentially a "counting sequence", transcendentals are not.

    To make is clear... Consider if the numbers are constrain to be between 1 and 199. The first digit will clearly be a 1 more than anything else (actually everything else combined)... But now look if the constraint is between 1 and 219. For numbers where the first digit is two, we have eliminated all used of 2 thru9 in the second digit, therefore increasing the probability of there being a 1 in the second digit across the board..The same logic can be extended for any number of digits.

    Now in the general case the (upper) bounds of the number is not known, therefore one calculates the percentages for every possible upper limit and uses the average. Since there are no upper limits where the probability of a higher digit will exceed (it may equal) that of a lower digit, and since there are limits where the probability of a lower digit, in any position, will be higher, the generalization holds.

    What? No.  It doesn't apply to counting sequences at all.  It applies to natural sequences. 


  • @Sutherlands said:

    What? No.  It doesn't apply to counting sequences at all.  It applies to natural sequences. 

    You are correct, I was not being mathematically correct. My intent was to indicate that it applied when the set of numbers starts at 1 (or 0), increments by 1, and has a uniform distribution.

    An example where it would not apply is speed limits. In the USA these range from 5mph to 75mph and almost invariably are a multiple of 5 (I have seen one legitimate sign in my life that was not). As a result, this set of numbers would have a radically different distribution of digits.



  • @TheCPUWizard said:

    My intent was to indicate that it applied when the set of numbers starts at 1 (or 0), increments by 1, and has a uniform distribution.

    That's still not what it applies to.  The distribution is nothing alike.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.