Using the Windows event log won't help much. I guess in your case elogd is driven into some kind of endless loop (does the CPU go to 100%???). There are only two possibilities to tackle this:

1) You find a way to reliably reproduce this problem, tell me how to do this. When I can reproduce it here, I can fix it easily.

2) You do debugging yourself. Under Linux this is simple, since you have debuggers on most systems. Under Windows however, you first have to install the Visual C++ development environment. I believe there is a free version (Express?) which you can use. You then run elogd under the debugger, and when it hangs you investigate where. This needs some basic knowledge about C++ development and I'm not sure if you have this, but maybe you can find someone around you who does. 

> When running openvas (a nessus fork) against elog 2.9.0 I provoked the following crash:
> 
> Apr  9 17:32:06 unixland elogd[1300]: POST / HTTP/1.0#015#012Host: unixland.home
> #015#012Content-Length: -800#015#012#015#012XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> 
> Apr  9 17:32:06 unixland kernel: [664894.491242] elogd[1300]: segfault at b7713d
> 2e ip 080b6956 sp bf8d5ea0 error 4 in elogd[8048000+96000]
> 
> openvas reports that it was testing for CVE-2002-1212 when the crash occurred.
> 
> Startup info:
> 
> Apr  9 19:35:54 unixland elogd[21584]: elogd 2.9.0 built Apr  9 2011, 17:49:08 
> Apr  9 19:35:54 unixland elogd[21584]: revision 2411
> 
> -- rouilj

I haven't tried openvas, but added a check for the negative content-length you have in the request
above in SVN revision 2413. Can you try if it still crashes?

- Stefan

> After upgrading from 2.3.1 to 2.3.3, elog is not able to load any resources
> as stylesheets, images or passwordfiles.
> 
> Cannot open file /usr/local/elogdata/logbooks/djeks/password!

If you installed from the RPM, elogd runs under the user "elog". If you have 
installed a previous version under a different user, it might be that elogd 
does not have read or write access to it. A 

"chown -R elog.elog /usr/local/elogdata"

might help.

- Stefan

> > After upgrading from 2.3.1 to 2.3.3, elog is not able to load any resources
> > as stylesheets, images or passwordfiles.
> > 
> > Cannot open file /usr/local/elogdata/logbooks/djeks/password!
> 
> If you installed from the RPM, elogd runs under the user "elog". If you have 
> installed a previous version under a different user, it might be that elogd 
> does not have read or write access to it. A 
> 
> "chown -R elog.elog /usr/local/elogdata"
> 
> might help.
>
 
It did, a lot, guess I missed that one in the changelog.

Had some trouble with subdir too:
changed it to its full path
restarted elogd
worked

As a test I changed subdir to it's relative path
restarted
It kept working

mmmm, I wonder where that twighlight tune comes from ...

I see the same problem with IE. The knowledge base says that one should remove the "no-cache" statement from the header, but that has strange side effects: Assume you export a logbook to a CSV file, and a few days later you export it again, since many things changed. But you browser will in that case not retrieve the new logbook, but read the old CSV file from the cache. But the browser does not tell you this, so you see an old version of the logbok without knowing this, which can be dangerous. So I better leave the "no-cache" in the header. The workaroung is not to click on "Save" on the file download dialog, but on "Open". You see then the CSV data inside the browser and can copy/paste it into a notepad document, then save it. 

 Ah, now this is humorous, when the client first came to me, that was almost exactly the work around I gave him, open it, CTRL-A to highlight it all, CTRL-C to copy it, Move to the excel spreadsheet, CTRL-V to paste it into Excel. Select Data, Text to Columns, and you have an Excel Spreadsheet.   They wanted me to post the change in function anyway, though I told Vamsi, "just watch, someone will post the same workaround that I already gave to the clients".  So you see why I find it amusing.  I would say Great Minds Think Alike, but that would be giving myself a bit too much credit (grin).  First, thank you for proving me right on my prediction and if you should happen to make a change that would get around this SSL change in behavior, it would make a group of manufacturing types that are not quite as comfortable with computers as we are, very happy.   Please let us know.

I can easily remove the "no-cache" from the header, but as I wrote you, people can then shoot themselves into the foot by getting an old document, and I guess they become even less happy then. So you tell me which way you prefer. 

 Trust me, I don't want them getting old data either.. that would be a nightmare..

of course, the little voice at the back of my head (note, not IN the back of my head) has offered up this tidbit for you to consider.

Stefan, would it be possible to make the following change so that the document is not cached and at the same time it is possible to save it.

The change would entail replacing the "Pragma: no-cache" directive with an "Expires: " <HTTP-date> where <HTTP-date> is the same as Date header value. Please see section 14.21 of http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Hopefully there are no other side effects to this change.