Win32 process exits with code 1

What does it mean when my own Win32 app randomly exits with error code 1 (apparently ERROR_INVALID_FUNCTION according to MSDN), despite it not being programmed to do so?
I've been trying to find the bug in the code for hours, with no success. There are 2000 lines of code. I tried setting up exception handlers so I could see if it's a segmentation fault (SetUnhandledExceptionFilter lets me debug the address where the error occurred), but the problem is really weird in this case: the exception filter is never triggered, nor does the app pop up the usual "Report Error To Microsoft" dialog if I don't set an exception handler. I first thought it's a stack overflow since those don't pop up a dialog, but after some testing I realized the UnhandledExceptionFilter actually detects stack overflows, so it isn't that (the filter is not triggered by the bug, nor can I find anything that could possibly cause a stack overflow from the code).
There are no ExitProcess/ExitThread calls in the process that return a "1". "1" is never returned by the main() function. The process does not leak memory. Large structs are not pushed on the stack.

As I said, address-based debugging is not an option since the process exits normally with code 1. That's why I am asking what could possibly cause a process to auto-return the value "1" in 32-bit Windows XP.
This bug is randomly triggered, which makes debugging even harder since the code executes dozens of functions millions of times. No specific function seems to be the cause of the bug. The process can sometimes run just fine for hours, and then begins crashing randomly every minute or so. Currently I'm using a program that simply restarts the process if it crashes, but I'm looking for the source of the problem..

Oh and the compiler debug shit is not triggered either, if I compile that option on..

There are no ExitProcess/ExitThread calls in the process that return a "1".
Not in your executable, you mean? There may be plenty of libraries loaded along with it and my guess is the issue is happening in one of those. Load it in a debugger, set a breakpoint on ExitProcess, and let it run until it breaks. Then examine the call stack and follow from there.

>>3
Load it in a debugger, set a breakpoint on ExitProcess, and let it run until it breaks. Then examine the call stack and follow from there.

I just did that and actually found the function that causes the bug, so thanks for that (should have done that in the first place), but I still have no idea why the bug is caused. I managed to add a fix though. Also, OllyDbg thinks the process exits with code 0 instead of 1 when the bug occurs.
I understand how the bug could cause the program to not behave quite as intended, but I have absolutely no idea why the program just exits without any errors. Wasn't related to libraries either. Oh well, see no evil, hear no evil, speak no evil.

but I have absolutely no idea why the program just exits without any errors.
If you really want to know, trace up the call stack.
Wasn't related to libraries either.
Your program is at least linked against kernel32 (where does ExitProcess come from?) and probably several others.

Also, OllyDbg thinks the process exits with code 0 instead of 1 when the bug occurs.
Observer effect. This is a very big issue when software has specific anti-debugging code, but in general if your debugger is not hidden well enough it can be detected and cause things to behave differently (if I remember correctly MSVCRT will enable debug malloc() if it detects one), and for bug-hunting it may make a huge difference.