MemInfoMicro : The Return

[Antariy]

i need to buy some memory - lol

WinXP work nice with almost all stuff at 96 megs of RAM.
With 64 megs it works well without many not needed stuffs. With 48 megs it woooooooorrrrrrrkkkkkksssssss........  :P

You screenshot have a plus - it show what program differently shows units of size, and really change color of indicator  :P



Alex

[Antariy]

On Vista, the program does not exit properly (each instance of the process remains in task manager, and must be killed manually).  Otherwise, nice work. 

Alan, does not you see title of thread?
It is: Re: MemInfoMicro : The Return. And return to OS for exit... is not work. That is planned, "We made that bug planned" :green2

Jokes apart - there are no place for implementation of ExitProcess.
Nice Vista create other thread somewhere (I guess - at MessageBeep).
Alan, can you find and disable call to MessageBeep, and after this check app?


Most good solution (close your ears  :green2) woud be silent crash of application - for termination.  :bg



Alex

[Antariy]

Without MessageBeep program can stand smaller :green2

On other hand, if use DEP-incompatible variant (which have size 984 bytes), we have much more space for ExitProcess + MessageBeep.
But that variant would not work with DEP enabled systems (because part of the code in a "bad place").



Alex

[GregL]

On Vista, the program does not exit properly (each instance of the process remains in task manager, and must be killed manually).

I'm running Vista on my laptop and it exits properly. ??

[redskull]

I run Vista Home Premium, sp2, 32-bit.  i'm going to try to do that fancy jpeg as zip attachment, but no promises.

-r


This is a snap of process manager, after starting and stopping a few.  Please, no jokes about using eclipse (it's for school, i promise  :bg 0

[Antariy]

I'm running Vista on my laptop and it exits properly. ??

There are strange matter, in any case. Many times ago, I stubled with thing - under Win2k program is not terminated after ShellExecute, if it is exited from main (and only one) thread by RET, not by ExitProcess. Under XP and 9x it works well.

There are the same strange thing. First my think was that some API (I thinked MessageBeep) create different thread, and it prevent app to close.

In any way, if switch using of MessageBeep to ExitProcess, I can get this program to work with small changements.

So, voting is opened: who argue for MessageBeep, and who for ExitProcess?

:bg



Alex

[Antariy]

I run Vista Home Premium, sp2, 32-bit.  i'm going to try to do that fancy jpeg as zip attachment, but no promises.

Alan, TaskManager, and ProcessExplorer, can show threads count in working prog. Run the program, move it above screen and back, move mouse pointer to close button at title, wait before ToolTip was showed, but not close program! - and after this see count of threads please.
This is witch-doctors method, but this is based on some funny experience, really.



Alex

[redskull]

After that test, there are two threads running.  After hitting 'okay', one thread exits, and the other sticks around in "Wait:UserRequest" mode.  The stack for the remaining one is:

ntdll.dll!KiFastSystemCallRet
kernel32.dll!WaitForMultipleObjects+0x18
msiltcfg.dll!RestartMsi+0x327
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

[Antariy]

After that test, there are two threads running.  After hitting 'okay', one thread exits, and the other sticks around in "Wait:UserRequest" mode.

Well, as I decide initially, there are created one thread more into some API.
Very nice thing.  :green2
Wait:UserRequest almost always meant what some window is waits for input. Of course, there are hidden window which created by system for "a good purpose - just in case"  :green2

Strage thing what member of the ball is MSI subsystem??? Initially I guess that this is would be sndPlaySound...

NOTE: program does not create any threads itself - it just runned in main thread, and exit from it by RET. Creation of other thread is not planned, more over, this *must* not be done.
I'm not use any APIs which is creates threads, but initially I guessed that MessageBeep under Vista do this.

So, how be with voting?



Alex

[redskull]

I would assume the second thread is started by the message dialog routine.  After stepping through it, there is one thread present before and after the message beep, a second one starts up after calling MessageBoxIndirect, but *does not* terminate after the message box has been closed.  It is that same thread that stays active after the program has 'ended'.  My hypothesis is that the dialog box thread is not being ended properly.

Also, the symbol names are garbage, don't assume anything based on them  :bg

-r

[Antariy]

I would assume the second thread is started by the message dialog routine.  After stepping through it, there is one thread present before and after the message beep, a second one starts up after calling MessageBoxIndirect, but *does not* terminate after the message box has been closed.  It is that same thread that stays active after the program has 'ended'.  My hypothesis is that the dialog box thread is not being ended properly.

Also, the symbol names are garbage, don't assume anything based on them  :bg

Well, I *do not create any dialogs* I just call to MessageBoxA. There is a bug or oversight in Vista code, probably. If MessageBox->... create new thread, it *must* terminate it, I decide. There is law of programming - if you create - you must destroy.



Alex

[GregL]

I'm only seeing one thread.  I'm also running Vista Home Premium SP2 32-bit.

Processor is:  Intel(R) Core(TM)2 Duo CPU T5750  @ 2.00GHz.

[Antariy]

I'm only seeing one thread.

This can be hard to find stuff - some of shell extensions can hook program. Any other program can hook my program - create thread with its own Window (for simple interconnection with "server") etc. Moreover - COM creates hidden window for objects which is not designed for multithreading.
In short words, if Windows *wants* to do something that we are don't wait - it don't say to us about this...

Probably I'll change call to MessageBeep to call to ExitProcess, wich appropriate changements at executable.

Thanks to all for tests and attention! Good day/evening/night!



Alex

[redskull]

It's tough without source, but here's what the debugger is showing:

Code Select Expand

0040119c ff5314          call    dword ptr [ebx+14h]  ds:0023:00401014={user32!MessageBeep (75dde42b)}
0040119f ff5318          call    dword ptr [ebx+18h]  ds:0023:00401018={user32!MessageBoxIndirectA (75e0d4d9)}

Both these "work", in that the first makes the computer beep and the second brings up the dialog (and creates the thread that never exits).  I hope someone can corroborate my findings, or i'll think i'm going crazy.

-r

[Antariy]

It's tough without source, but here's what the debugger is showing:

Code Select Expand

0040119c ff5314          call    dword ptr [ebx+14h]  ds:0023:00401014={user32!MessageBeep (75dde42b)}
0040119f ff5318          call    dword ptr [ebx+18h]  ds:0023:00401018={user32!MessageBoxIndirectA (75e0d4d9)}

Both these "work", in that the first makes the computer beep and the second brings up the dialog (and creates the thread that never exits).  I hope someone can corroborate my findings, or i'll think i'm going crazy.

Yes, first call is to MessageBeep, second to MessageBoxInderectA, really this is have no meaning under XP and above - call to MessageBox/Ex/Indirect go by one way - SoftModalMessageBox.

You are not crazy  :bg, param for MessageBoxIndirect is passed before param to MessageBeep.

So, when you are trace, when program calls to MessageBeep and exited from it (i.e. - step over), but don't call yet to MessageBox, exists only one thread?

EDITED: sources does not exist, really.



Alex