I''ve noticed this a lot lately, and it''s really bugging me. My Win32 program has an "extra" thread, that runs during the program and then quits after a variable amount of time (usually between 5-30 seconds) if I switch to other apps while it''s running. If I don''t switch to another app and instead just end my program, the debug window of VC++ 6 shows that "extra" thread as returning an exit code of -1. I understand this to mean that the thread did not shut down properly. Has anyone else had this problem? Is it a problem with my initialization code? Or my WndProc? P.S. If I create the sample (via AppWizard) Win32 "Hello World!" app, that thread is there, but always returns 0. Same thing for the sample MFC apps. Thanks! - null_pointer

I mostly have only MFC experience, but I''ve never noticed this other thread. I thought the default implementation has only one thread created when you instantiate theApp, has the message pump. You can make other threads, of course, but there''s only one in the framework. I''ll look harder, but I''ve never noticed more than one thread.

Stoffel: Check in the debug window (the bottom one in the IDE); the other thread exits right before the program exits. I know it's right before the program, because sometimes it exits before the program.

Here are the contents of the Debug window for the sample Win32 Hello World! app, although the thread's ID will be different for your program:

quote:
Loaded 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL', no matching symbolic information found.
Loaded 'C:\WINDOWS\SYSTEM\GDI32.DLL', no matching symbolic information found.
Loaded 'C:\WINDOWS\SYSTEM\KERNEL32.DLL', no matching symbolic information found.
Loaded 'C:\WINDOWS\SYSTEM\USER32.DLL', no matching symbolic information found.
The thread 0xFFF42377 has exited with code 0 (0x0).
The program 'C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\MYPROJECTS\Test\Debug\Test.exe' has exited with code 0 (0x0).

Although in my app, that "extra" thread's exit code is -1.

Thanks!


- null_pointer


Edited by - null_pointer on 3/6/00 5:32:52 PM

I count one thread. The last message is printed when either the original thread or the last thread exits (I forget which).

Edited by - Stoffel on 3/6/00 6:56:11 PM

I have had the same problem with my code having an "extra thread".
It always exits after about 15 seconds, and the game jolts slightly, but then behaves okay. The only thought that I ever had was that maybe this had something to do with the debugger/debug release, or possibly the initialization of some directX component???
I know this wasn''t much help, but at least you know you''re not alone

Stoffel: The main program has an exit code, and that "extra" thread has an exit code. I didn't create any threads with CreateThread or _beginthread or whatever. They are two separate threads (one called a thread in the debug window and one called a program), because, as I said before, when my program is running, the other thread exits. My program is still running; the "extra" thread has already quit. I can leave my program running -- even break into WinMain() -- when that "extra" thread has already finished and printed its exit code to the debugger's window. I am aware of the fact that the program itself is simply the main thread; that's why I called it an "extra" thread. I'm sorry if I didn't make that clear before. I'd just like to know what it is.

Thanks!


- null_pointer


Edited by - null_pointer on 3/8/00 10:53:19 AM

The thread 0xFFF42377 has exited with code 0 (0x0).
The program ''C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\MYPROJECTS\Test\Debug\Test.exe'' has exited with code 0 (0x0).


Thread 0xFFF42377 is not an extra thread, it''s the main thread of the application. A thread exiting and a process exiting are two different things. I''m almost positive about this, I may be wrong.


"That which the flame does not consume...consumes the flame. "

Nottingham: Nope! I wish it was that easy -- but the "extra" thread sends this message to the debugger:

quote:
The thread 0xFFF42377 has exited with code 0 (0x0).

WHILE the program is still running. I can let the program run for 1/2 hour after this "extra" thread has closed. It is NOT part of the program.

Sorry for getting irritable -- it''s just that I''ve explained this like three times now... and if you don''t believe me, build the sample app and test it for yourself.


- null_pointer

OK, put down the pipe, null.

I just compiled a basic program, using MFC (in case there was some mystery thread in it) in VC++ 6.0. Settings were SDI, no Doc/View support. Running the program, I got the following only after I hit close:

The thread 0x135 has exited with code 0 (0x0).
The program ''C:\projects\hello\Debug\hello.exe'' has exited with code 0 (0x0).

There were no other thread exit messages before I hit close. Nothing closed at some time into the program.

It has been my contention that the second exit code is the process exiting, which returns either the return value of the last thread or the original (I''m not sure which). You said this was untrue. In order to test this theory, I overrode my app''s ExitInstance function, the return value of which is the main thread''s return code. I set the thread''s code to -1. Observe:

The thread 0x128 has exited with code -1 (0xFFFFFFFF).
The program ''C:\projects\hello\Debug\hello.exe'' has exited with code -1 (0xFFFFFFFF).

There is one thread and one process, each of which has a corresponding line above. This is what we all said at first. Please, just accept it. If you have another thread lasting 10 seconds somewhere, I''m sorry, but it''s not VC++ doing it behind your back. None of us are seeing whatever you''re seeing. I just don''t know how else to put it. Best of luck.

gonna have to concur with Stoffel. Built the sample app and the expected result. If you still don''t believe us, whip out Spy++ and look at the threads. It''ll tell you what threads are connected to that process and their IDs

"That which the flame does not consume...consumes the flame. "