After Daniel patched the Win32-EventLog code to properly handle "strange" event messages (I'll leave it to Daniel to explain that) my program started working, but then dies. Here's the full text of the program:
require 'win32/eventlog'
include Win32
log = EventLog.open("Application")
log.read do |rec|
puts rec.inspect if rec.source == 'sshd'
end
I wrote this script because I've been getting thousands of infiltration attempts via ssh, and I wanted to pull all the ssh messages out and do "something" with them. I've been running the script thusly;
ruby el.rb > el.out
It runs for a few/several seconds then dies with this:
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
The output in the redirected file is truncated when the process died. I've tried outputting to a file directly instead of just going to stdout and redirecting, but it does the same thing. The last run I did was a few minutes ago, and the output file had 1433 complete lines (the #inspect gets everything on one line) and 1 truncated line. There are many more events still to be read.
Does this ring a bell with anyone?
Here are my vitals:
ruby 1.8.2 (2004-07-29) [i386-mswin32]
WindowsXP Pro sp1
Win32-EventLog - built from CVS on 10/14.
Joey
···
--
She drove a Plymouth Satellite
Faster than the Speed of Light...
http://www.joeygibson.com/blog
Atlanta Ruby User Group http://www.AtlRUG.org
Joey Gibson <joey@joeygibson.com> wrote in message news:<4173E120.80106@joeygibson.com>...
After Daniel patched the Win32-EventLog code to properly handle
"strange" event messages (I'll leave it to Daniel to explain that) my
program started working, but then dies. Here's the full text of the program:
require 'win32/eventlog'
include Win32
log = EventLog.open("Application")
log.read do |rec|
puts rec.inspect if rec.source == 'sshd'
end
I wrote this script because I've been getting thousands of infiltration
attempts via ssh, and I wanted to pull all the ssh messages out and do
"something" with them. I've been running the script thusly;
ruby el.rb > el.out
It runs for a few/several seconds then dies with this:
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
The output in the redirected file is truncated when the process died.
I've tried outputting to a file directly instead of just going to stdout
and redirecting, but it does the same thing. The last run I did was a
few minutes ago, and the output file had 1433 complete lines (the
#inspect gets everything on one line) and 1 truncated line. There are
many more events still to be read.
Does this ring a bell with anyone?
Here are my vitals:
ruby 1.8.2 (2004-07-29) [i386-mswin32]
WindowsXP Pro sp1
Win32-EventLog - built from CVS on 10/14.
Joey
Hi Joey,
After getting home from work today I tried again on my home machine.
My "System" log has over 1700 messages in it, but a test script with
no failure. I intentionally wrote several hundred event log messages
to my application log - about 2500 in total - and I still couldn't get
it to fail.
So, my gut feeling now is that it's not the quantity of messages, but
something about one message in particular that's causing it to crash.
Is there any chance you can narrow down a particular message it's
failing on? Is it always at the same point? Perhaps something about
the quantity or formatting of the event description is causing a
problem.
Regards,
Dan
Joey Gibson <joey@joeygibson.com> wrote in message news:<4173E120.80106@joeygibson.com>...
After Daniel patched the Win32-EventLog code to properly handle
"strange" event messages (I'll leave it to Daniel to explain that) my
program started working, but then dies. Here's the full text of the program:
<snip>
Fixed in 0.2.4 (thanks Park!).
It seems that you had a corrupt entry in your logfile which was
causing win32-eventlog to choke.
Regards,
Dan
Daniel Berger wrote:
After getting home from work today I tried again on my home machine. My "System" log has over 1700 messages in it, but a test script with
no failure. I intentionally wrote several hundred event log messages
to my application log - about 2500 in total - and I still couldn't get
it to fail.
My Application log (the one that I'm trying to work with) has 2084 records in it.
So, my gut feeling now is that it's not the quantity of messages, but
something about one message in particular that's causing it to crash.
I ran my test and wrote down the record number of the last one that showed up in the file. I will wait a little while until there are some more records (or I may add some myself...) and see if that number comes up again.
Is there any way to just grab a particular record instead of iterating the entire collection? I notice that the EventLog class doesn't mixin Enumerable; was this by design or is it a consequence of having C code underneath? Just wondering.
Is there any chance you can narrow down a particular message it's
failing on? Is it always at the same point? Perhaps something about
the quantity or formatting of the event description is causing a
problem.
I'll let you know as soon as I have some more results.
Joey
Daniel Berger wrote:
Is there any chance you can narrow down a particular message it's
failing on? Is it always at the same point? Perhaps something about
the quantity or formatting of the event description is causing a
problem.
It was obviously something with one or a few of the messages in the log because once I cleared the log and then added more records, everything worked fine. I did a backup of the log, but I'm not sure what to do with it. If I can figure out what to do with it, perhaps I can investigate further...
I pushed 3668 messages into the log and my program read all of them, so it looks like your code is indeed sound.
Thanks for the help, and I'll poke around some more to see if I can spot anything...
···
--
She drove a Plymouth Satellite
Faster than the Speed of Light...
http://www.joeygibson.com/blog
Atlanta Ruby User Group http://www.AtlRUG.org
Daniel Berger wrote:
Fixed in 0.2.4 (thanks Park!).
It seems that you had a corrupt entry in your logfile which was
causing win32-eventlog to choke.
Excellent! Thanks for slogging through my log to figure it out. This will help me whack the script kiddies who keep trying to hack my system... maybe...
Joey
···
--
She drove a Plymouth Satellite
Faster than the Speed of Light...
http://www.joeygibson.com/blog
Atlanta Ruby User Group http://www.AtlRUG.org
Joey Gibson wrote:
Daniel Berger wrote:
Is there any chance you can narrow down a particular message it's
failing on? Is it always at the same point? Perhaps something about
the quantity or formatting of the event description is causing a
problem.
It was obviously something with one or a few of the messages in the log because once I cleared the log and then added more records, everything worked fine. I did a backup of the log, but I'm not sure what to do with it. If I can figure out what to do with it, perhaps I can investigate further...
Once upon a time there was ...
... Python, WinNT4, the EventLog and me.
I just wanted to read the Eventlog with a Python app and it frequently crashed. Luckily Python is OpenSource so i tried debugging it. What i found out is, that the process crashed in a native WinNT function when this function tried to access one special EventLog entry. This entry was special because the messsage provider for this EventLog entry did not exist any longer at this workstation because i deinstalled the application that was meant to provide the message provider. So the attributes of this entry pointed to some invalid message provider that caused the function to fail. There was nothing one could do, except deleting this particular entry from the eventlog. Such thing can easily happen if you upgrade, downgrade or deinstall applications.
Maybe it is related to your experience.
Well, and i am not living together with WinNT4, EventLog and Python until the end of my live. But i am still happy 
Gruß
Jan
Jan Krüger <jk@microgalaxy.net> wrote in message news:<41751280.20401@microgalaxy.net>...
Joey Gibson wrote:
> Daniel Berger wrote:
>
>> Is there any chance you can narrow down a particular message it's
>> failing on? Is it always at the same point? Perhaps something about
>> the quantity or formatting of the event description is causing a
>> problem.
>>
>
> It was obviously something with one or a few of the messages in the log
> because once I cleared the log and then added more records, everything
> worked fine. I did a backup of the log, but I'm not sure what to do with
> it. If I can figure out what to do with it, perhaps I can investigate
> further...
Once upon a time there was ...
.. Python, WinNT4, the EventLog and me.
I just wanted to read the Eventlog with a Python app and it frequently
crashed. Luckily Python is OpenSource so i tried debugging it. What i
found out is, that the process crashed in a native WinNT function when
this function tried to access one special EventLog entry. This entry
was special because the messsage provider for this EventLog entry did
not exist any longer at this workstation because i deinstalled the
application that was meant to provide the message provider. So the
attributes of this entry pointed to some invalid message provider that
caused the function to fail. There was nothing one could do, except
deleting this particular entry from the eventlog. Such thing can
easily happen if you upgrade, downgrade or deinstall applications.
Maybe it is related to your experience.
Well, and i am not living together with WinNT4, EventLog and Python
until the end of my live. But i am still happy
GruÃÂ
Jan
I tested the scenario you mention, but could not duplicate the
problem. In testing, if the eventlog source for an eventlog entry is
deleted, it seems to merely skip those. It didn't cause a problem on
my Windows box. Perhaps that was an NT 4 issue, or perhaps it was a
problem with older versions of the libs.
In this case, however, I've determined that it's definitely something
in the log itself. If I try to read the backup file, it crashes on me
consistently just after record number 5458.
So, now I need to figure out what the heck is up with this particular
log entry that's causing the problem.
Regards,
Dan