When I start Workrave, it immediately crashes.  The following dialog is displayed:

 Workrave.exe - Application Error

 The instruction at "0x0126c8d0" referenced memory at "0x00000000".  The memory
could not be "written".

 Click OK to terminate the program
 Click on CANCEL to debug the program

I'll attach the log generated after I clicked on Cancel.

Created attachment 9
crash log

A couple of questions, as I cannot reproduce this (and haven't heard similar
reports from others):
- Are you running 0.1.0, or 0.2.0 ?
- Are you running any other Workrave-like tool ? (tools monitoring user input
may conflict with each other).
- You noted that you are running W2000. Have you installed anything worth
noting, such as a service pack installed?
- Do you have any other programs installed that are built using Gtk, such as the
Gimp for example?

> - Are you running 0.1.0, or 0.2.0 ?

This report was based on 0.2.0, but a similar problem occurred with 0.1.0.  The
address of the violating instruction was different, and I wasn't able to find
the log.

> - Are you running any other Workrave-like tool ? (tools monitoring user input
may conflict with each other).

I'm running OosTime now, but I wasn't when this crash occurred.

> - You noted that you are running W2000. Have you installed anything worth
noting, such as a service pack installed?

Microsoft Windows 2000
5.00.2195
Service Pack 2

> - Do you have any other programs installed that are built using Gtk, such as the
Gimp for example?

Yes, I have WinGimp 1.2.3 installed, and it works.

Could you please try deinstalling WinGimp (Gtk specifically) to see if that
corrects the problem? Make sure that all Gtk DLLs are removed from the system.
Perhaps Workrave is mistakenly linking to the Gtk DLLs provided by WinGimp
instead of its own...

Uninstalled WinGimp, no change.

I've compiled a debug version that hopefully gives some more insight in what is
happening. Could you please try the following?:

1) Download:
http://workrave.sourceforge.net/files/workrave-win32-20021007-installer.exe
2) Download: 
http://workrave.sourceforge.net/files/workrave-win32-20021007-debug.exe
3) Install the installer version.
4) Replace \Program files\Workrave\Workrave.exe by the debug.exe.
5) Start the program

The debug version generates some debugging output. Could you please send that to us?

Thanks in advance.

Created attachment 10
Here is the output of the debugging executable.  It continues printing mouse_hook lines until I dismiss the dialog.

Ah, now we are getting somewhere, it looks like a problem in harpoon.dll, our
user input monitor. You mention it repeatedly prints the last line of your log?:

>>> Win32InputMonitor::mouse_hook 512, (323, 513, 0)

Are all these lines unique, or do the numbers printed vary? (323,513) is should
equal your mouse coordinates. Do these numbers change when your mouse is moved?

It prints the last type of line when I move the mouse, and the numbers in
parentheses do change.  I'm not sure about the first, but the rest all appear
*after* the dialog.

Hmm, if you see mouse_hooks while you are moving the mouse, that means that the
input monitor is running just fine. The last non input monitor entry appears to
be MainWindow::init, so that should be where the crash is then. I'm still a bit
puzzled... I'll get back to you later.

This bug is still present in 0.3.0, though the address of the offending
instruction is now 0x0128e0e8.

I can confirm this on Win2K SP3 w/ie6 sp1.  This was using a fresh install of 
Workrave v0.3.  Please let me know if I can help in resolving this bug.  
Thanks, Joe.

I think we've got this nailed down now, with the help of Joe Schwendt.
On his machine, there was a copy of zlib.dll in c:\winnt\system32. Workrave
loads that copy, instead of its own (c:\program files\workrave\lib\zlib.dll),
resulting in the crash.

Matt, could you please check if your problem is the same? You probably need to
uninstall the Gimp/Win32 again, and move c:\winnt\system32\zlib.dll out of the
way if it exists.

So, in order to solve this bug once and for all I need to figure out how to
force Workrave to load DLLs from its own path first...

Yep, renaming c:\winnt\system32\zlib.dll to c:\winnt\system32\zlib.dll~ fixes
Workrave.  Thanks.

Fixed, it should now be safe to place your old/faulty zlib.dll in
c:\winnt\system32 again...