Why CorExitProcess?

In a pure Win32 app, let's say hello.c, the generated code uses
CorExitProcess funcion from mscoree.dll to finalize the app....

Why?

[]s
Fred

Carl
Thu Apr 13 08:45:41 CDT 2006

Frederico Pissarra wrote:
> In a pure Win32 app, let's say hello.c, the generated code uses
> CorExitProcess funcion from mscoree.dll to finalize the app....
>
> Why?

Because you compiled it with /clr. A pure win32 app will not have any
reference to mscoree.dll. Make sure you've really got your project settings
set correctly.

-cd

Frederico
Sat Apr 15 20:19:07 CDT 2006


"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@mvps.org.nospam>
wrote in message news:eH6TPCwXGHA.1196@TK2MSFTNGP03.phx.gbl...
> Frederico Pissarra wrote:
>> In a pure Win32 app, let's say hello.c, the generated code uses
>> CorExitProcess funcion from mscoree.dll to finalize the app....
>>
>> Why?
>
> Because you compiled it with /clr. A pure win32 app will not have any
> reference to mscoree.dll. Make sure you've really got your project
> settings set correctly.
>
> -cd
>

No... I don't compile with /clr... my compile command line was:

cl -Ox -GAF hello.c

even if I use -clr- (I don't know if this will turn /clr off!), the result
is the same!

Take a look at crt0dat.c in %msvcdir%/crt/src directory. There you can find
something like this:

------------%<--------------------------%<--------------------------
void __cdecl __crtCorExitProcess (
int status
)
{
HMODULE hmod;
PFN_EXIT_PROCESS pfn;

hmod = GetModuleHandle("mscoree.dll");
if (hmod != NULL) {
pfn = (PFN_EXIT_PROCESS)GetProcAddress(hmod, "CorExitProcess");
if (pfn != NULL) {
pfn(status);
}
}

/*
* Either mscoree.dll isn't loaded,
* or CorExitProcess isn't exported from mscoree.dll,
* or CorExitProcess returned (should never happen).
* Just call return.
*/
}

void __cdecl __crtExitProcess (
int status
)
{
__crtCorExitProcess(status);

/*
* Either mscoree.dll isn't loaded,
* or CorExitProcess isn't exported from mscoree.dll,
* or CorExitProcess returned (should never happen).
* Just call ExitProcess.
*/

ExitProcess(status);
}

------------%<--------------------------%<--------------------------

My question remains: Why to call CorExitProcess if my app is an Win32 App
(no .NET)?!?!

[]s
Fred

Jeff
Sat Apr 15 20:31:19 CDT 2006

"Frederico Pissarra" <me@nowhere.net> wrote in message
news:O2VadPPYGHA.4484@TK2MSFTNGP02.phx.gbl...
> Take a look at crt0dat.c in %msvcdir%/crt/src directory. There you can
> find something like this:
>
> ------------%<--------------------------%<--------------------------
> void __cdecl __crtCorExitProcess (
> int status
> )
> {
> HMODULE hmod;
> PFN_EXIT_PROCESS pfn;
>
> hmod = GetModuleHandle("mscoree.dll");
> if (hmod != NULL) {
> pfn = (PFN_EXIT_PROCESS)GetProcAddress(hmod, "CorExitProcess");
> if (pfn != NULL) {
> pfn(status);
> }
> }
> My question remains: Why to call CorExitProcess if my app is an Win32 App
> (no .NET)?!?!
>


If all you're talking about is the above, then my take on it is that the CRT
only calls CorExitProcess if mscoree.dll is already loaded, or rather only
if it needs to.

--
Jeff Partch [VC++ MVP]

Frederico
Sat Apr 15 20:44:28 CDT 2006


"Jeff Partch [MVP]" <jeffp@mvps.org> wrote in message
news:eutP4VPYGHA.2148@TK2MSFTNGP02.phx.gbl...
> "Frederico Pissarra" <me@nowhere.net> wrote in message
> news:O2VadPPYGHA.4484@TK2MSFTNGP02.phx.gbl...
>> Take a look at crt0dat.c in %msvcdir%/crt/src directory. There you can
>> find something like this:
>>
>> ------------%<--------------------------%<--------------------------
>> void __cdecl __crtCorExitProcess (
>> int status
>> )
>> {
>> HMODULE hmod;
>> PFN_EXIT_PROCESS pfn;
>>
>> hmod = GetModuleHandle("mscoree.dll");
>> if (hmod != NULL) {
>> pfn = (PFN_EXIT_PROCESS)GetProcAddress(hmod,
>> "CorExitProcess");
>> if (pfn != NULL) {
>> pfn(status);
>> }
>> }
>> My question remains: Why to call CorExitProcess if my app is an Win32 App
>> (no .NET)?!?!
>>
>
>
> If all you're talking about is the above, then my take on it is that the
> CRT only calls CorExitProcess if mscoree.dll is already loaded, or rather
> only if it needs to.
>
> --
> Jeff Partch [VC++ MVP]
>

Jeff... I realize that... but why?! If I use anything from CLR I'll expect
to see my program checking if mscoree.dll is loaded and trying to call
CorExitProcess... but my prog is a pure Win32 app... In that case there is a
dead code in my binary image.... I wonder if there are another surprises...

[]s
Fred

Jeff
Sat Apr 15 21:03:03 CDT 2006

"Frederico Pissarra" <me@nowhere.net> wrote in message
news:epB9ndPYGHA.4684@TK2MSFTNGP03.phx.gbl...
> If all you're talking about is the above, then my take on it is that the
>> CRT only calls CorExitProcess if mscoree.dll is already loaded, or rather
>> only if it needs to.
>
> Jeff... I realize that... but why?! If I use anything from CLR I'll expect
> to see my program checking if mscoree.dll is loaded and trying to call
> CorExitProcess... but my prog is a pure Win32 app... In that case there is
> a dead code in my binary image.... I wonder if there are another
> surprises...
>

Maybe I'm remembering wrong, but I though they did away with static linking
to the CRT?
--
Jeff Partch [VC++ MVP]

Bruno
Sun Apr 16 01:47:32 CDT 2006


> Maybe I'm remembering wrong, but I though they did away with static
> linking
> to the CRT?

with VC2005, you can still link statically to the CRT just fine with native
apps.
As soon as you need the CLR you have to switch to dynamic linking. static
linking to the CRT is not an option in that case.

It is decribed here:
http://msdn.microsoft.com/netframework/programming/breakingchanges/designtime/cplusplus.aspx
and in the documentation on /clr
http://msdn2.microsoft.com/en-us/library/k8d11d4s(VS.80).aspx

Note that the docs for VC2003 specifies the opposite.
there the documentation states that the static crt is in use when using /CLR
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/vcrefeecomcompilation.asp

--

Kind regards,
Bruno van Dooren
bruno_nos_pam_van_dooren@hotmail.com
Remove only "_nos_pam"

Frederico
Sun Apr 16 12:19:30 CDT 2006


"Jeff Partch [MVP]" <jeffp@mvps.org> wrote in message
news:uNBennPYGHA.3704@TK2MSFTNGP03.phx.gbl...
> "Frederico Pissarra" <me@nowhere.net> wrote in message
> news:epB9ndPYGHA.4684@TK2MSFTNGP03.phx.gbl...
>> If all you're talking about is the above, then my take on it is that the
>>> CRT only calls CorExitProcess if mscoree.dll is already loaded, or
>>> rather only if it needs to.
>>
>> Jeff... I realize that... but why?! If I use anything from CLR I'll
>> expect to see my program checking if mscoree.dll is loaded and trying to
>> call CorExitProcess... but my prog is a pure Win32 app... In that case
>> there is a dead code in my binary image.... I wonder if there are another
>> surprises...
>>
>
> Maybe I'm remembering wrong, but I though they did away with static
> linking to the CRT?
> --
> Jeff Partch [VC++ MVP]
>
>

Using -MT compiler option you are staticaly linking crt to the app.
But if you take a look at MSVCRT.DLL, CorExitProcess is there too!

[]s
Fred

Tim
Sun Apr 16 22:43:40 CDT 2006

"Frederico Pissarra" <me@nowhere.net> wrote:
>
>Jeff... I realize that... but why?! If I use anything from CLR I'll expect
>to see my program checking if mscoree.dll is loaded and trying to call
>CorExitProcess... but my prog is a pure Win32 app...

Maybe it is. Maybe it isn't. Are you 100% certain that none of the DLLs
that you load ever call into a DLL which calls into a DLL which calls into
a managed DLL? No, of course not. You can't possibly be certain. Neither
can the run-time library.

>In that case there is a dead code in my binary image....

Not dead code, just code that you aren't CERTAIN you don't need.

> I wonder if there are another surprises...

An infinite number, probably.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Igor
Mon Apr 17 07:20:01 CDT 2006

"Frederico Pissarra" <me@nowhere.net> wrote in message
news:u5iivoXYGHA.3328@TK2MSFTNGP02.phx.gbl
> But if you take a look at MSVCRT.DLL, CorExitProcess is there too!

I took a look - CorExitProcess is not there. At least not in the copy of
MSVCRT.DLL I have on my system.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

Frederico
Mon Apr 17 07:52:55 CDT 2006


"Igor Tandetnik" <itandetnik@mvps.org> escreveu na mensagem
news:ut7a$khYGHA.3496@TK2MSFTNGP05.phx.gbl...
> "Frederico Pissarra" <me@nowhere.net> wrote in message
> news:u5iivoXYGHA.3328@TK2MSFTNGP02.phx.gbl
>> But if you take a look at MSVCRT.DLL, CorExitProcess is there too!
>
> I took a look - CorExitProcess is not there. At least not in the copy of
> MSVCRT.DLL I have on my system.
> --

MSVCRT.DLL from 04/08/2004, 343040 bytes long, at offset 0x03494

[]s
Fred

Frederico
Mon Apr 17 07:57:45 CDT 2006


"Tim Roberts" <timr@probo.com> escreveu na mensagem
news:2k3642t565nppfelv6erdnujb972bc3j1i@4ax.com...
> "Frederico Pissarra" <me@nowhere.net> wrote:
>>
>>Jeff... I realize that... but why?! If I use anything from CLR I'll expect
>>to see my program checking if mscoree.dll is loaded and trying to call
>>CorExitProcess... but my prog is a pure Win32 app...
>
> Maybe it is. Maybe it isn't. Are you 100% certain that none of the DLLs
> that you load ever call into a DLL which calls into a DLL which calls into
> a managed DLL? No, of course not. You can't possibly be certain.
> Neither
> can the run-time library.
>

But I'm absolute certain that my code is 100% pure and don't use any CLR
artifacts....
Try this:

#include <stdio.h>

void main(void) { printf("hello\n"); }

and mscroree.dll and CorExitProcess will be there!

>>In that case there is a dead code in my binary image....
>
> Not dead code, just code that you aren't CERTAIN you don't need.
>
>> I wonder if there are another surprises...
>
> An infinite number, probably.

That's why, probably, I'll migrate all my apps to linux...
Surprises in an Development environment is something not appealing to me...

> --
> - Tim Roberts, timr@probo.com
> Providenza & Boekelheide, Inc.

[]s
Fred

Ivan
Mon Apr 17 12:52:59 CDT 2006

I guess Tim's point was:
Are you sure that your application will never host managed code ?

For example, if you call some RegQueryValue for performance
counter, and the performance coutner libraries are implemented
in Managed C++ and/or C++/CLR, then you are loading
mscoree.dll/mscorwks.dll. In that case, the ordered process
shoutdown needs to be coordinated with the CLR Runtime.
Unwillingfully hosting the CLR may not be that uncommon.

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Frederico Pissarra" <me@nowhere.net> wrote in message
news:eIhSH6hYGHA.3448@TK2MSFTNGP04.phx.gbl...
>
> "Tim Roberts" <timr@probo.com> escreveu na mensagem
> news:2k3642t565nppfelv6erdnujb972bc3j1i@4ax.com...
>> "Frederico Pissarra" <me@nowhere.net> wrote:
>>>
>>>Jeff... I realize that... but why?! If I use anything from CLR I'll
>>>expect
>>>to see my program checking if mscoree.dll is loaded and trying to call
>>>CorExitProcess... but my prog is a pure Win32 app...
>>
>> Maybe it is. Maybe it isn't. Are you 100% certain that none of the DLLs
>> that you load ever call into a DLL which calls into a DLL which calls
>> into
>> a managed DLL? No, of course not. You can't possibly be certain.
>> Neither
>> can the run-time library.
>>
>
> But I'm absolute certain that my code is 100% pure and don't use any CLR
> artifacts....
> Try this:
>
> #include <stdio.h>
>
> void main(void) { printf("hello\n"); }
>
> and mscroree.dll and CorExitProcess will be there!
>
>>>In that case there is a dead code in my binary image....
>>
>> Not dead code, just code that you aren't CERTAIN you don't need.
>>
>>> I wonder if there are another surprises...
>>
>> An infinite number, probably.
>
> That's why, probably, I'll migrate all my apps to linux...
> Surprises in an Development environment is something not appealing to
> me...
>
>> --
>> - Tim Roberts, timr@probo.com
>> Providenza & Boekelheide, Inc.
>
> []s
> Fred
>

Frederico
Tue Apr 18 19:22:40 CDT 2006


"Ivan Brugiolo [MSFT]" <Ivan.Brugiolo@online.microsoft.com> wrote in message
news:eL1dOxkYGHA.4248@TK2MSFTNGP05.phx.gbl...
>I guess Tim's point was:
> Are you sure that your application will never host managed code ?
>
> For example, if you call some RegQueryValue for performance
> counter, and the performance coutner libraries are implemented
> in Managed C++ and/or C++/CLR, then you are loading
> mscoree.dll/mscorwks.dll. In that case, the ordered process
> shoutdown needs to be coordinated with the CLR Runtime.
> Unwillingfully hosting the CLR may not be that uncommon.
>
> --

Ivan, I got that... and my point is even if my app ever use any CLR resource
I'm forced to have dead code in my apps... As I said before: I wonder what
other surprises MS put in the compiler/libraries...

[]s
Fred

Tim
Wed Apr 19 00:32:09 CDT 2006

"Frederico Pissarra" <me@nowhere.net> wrote:
>
>Ivan, I got that... and my point is even if my app ever use any CLR resource
>I'm forced to have dead code in my apps... As I said before: I wonder what
>other surprises MS put in the compiler/libraries...

Why are you worried about this? The run-time library also has code to call
the destructors for all of your global C++ objects, even if your program is
written in C. Do you consider that "surprising" dead code?
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Frederico
Thu Apr 20 00:54:42 CDT 2006


"Tim Roberts" <timr@probo.com> wrote in message
news:loib42191grjnec1dq8j9l1ahdbf0kl27e@4ax.com...
> "Frederico Pissarra" <me@nowhere.net> wrote:
>>
>>Ivan, I got that... and my point is even if my app ever use any CLR
>>resource
>>I'm forced to have dead code in my apps... As I said before: I wonder what
>>other surprises MS put in the compiler/libraries...
>
> Why are you worried about this? The run-time library also has code to
> call
> the destructors for all of your global C++ objects, even if your program
> is
> written in C. Do you consider that "surprising" dead code?
> --
> - Tim Roberts, timr@probo.com
> Providenza & Boekelheide, Inc.

The point is to have CLR dead code in a pure Win32 App...

It's expected to have init/cleanup hidden code in every C/C++ app, but not
"cross platform" dead code.

[]s
Fred

Ivan
Thu Apr 20 03:56:02 CDT 2006

The MS C-Runtime implementations offers features such as
- calling "atexit()" handlers in C++ applications (a `C` feature in C++)
- calling "unexpected" when an exception is not caught by
any exception list (a `C++` feature in `C`)
- cleanly allowing mscoree.dll to invoke Finalizers.

For example, feature #2 installs an UnHandledExceptionFilter,
that may be unwanted for those case where there are no exceptions.
But, the code would be not any more complex
(5-10 lines in the implementation) than the one that calls CorExitProcess
when necessary.
Writing a runtime that fits exactly and all the needs of a specific "domain"
would imply creating an un-necessary complication on the infrastrucutre.
Immagine linking a C++-but-not-C runtime, a CLR-but-not-C++ runtime,
a C-but-not-C++ runtime, and explaining people why certain feature
works (or do not work) as they would legitimately expect.
If it makes you feel better, since WinXp the NtDll-User-mode loader
has been modified to recognize the COR+2.0 images, so, even the
OS is CLR aware.
The code that possibly invokes CorExitProcess should never be more than
a few hundreds of bytes of compiled code.

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Frederico Pissarra" <me@nowhere.net> wrote in message
news:OTtXQ9DZGHA.4164@TK2MSFTNGP04.phx.gbl...
>
> "Tim Roberts" <timr@probo.com> wrote in message
> news:loib42191grjnec1dq8j9l1ahdbf0kl27e@4ax.com...
>> "Frederico Pissarra" <me@nowhere.net> wrote:
>>>
>>>Ivan, I got that... and my point is even if my app ever use any CLR
>>>resource
>>>I'm forced to have dead code in my apps... As I said before: I wonder
>>>what
>>>other surprises MS put in the compiler/libraries...
>>
>> Why are you worried about this? The run-time library also has code to
>> call
>> the destructors for all of your global C++ objects, even if your program
>> is
>> written in C. Do you consider that "surprising" dead code?
>> --
>> - Tim Roberts, timr@probo.com
>> Providenza & Boekelheide, Inc.
>
> The point is to have CLR dead code in a pure Win32 App...
>
> It's expected to have init/cleanup hidden code in every C/C++ app, but not
> "cross platform" dead code.
>
> []s
> Fred
>

Frederico
Thu Apr 20 11:02:28 CDT 2006


"Ivan Brugiolo [MSFT]" <Ivan.Brugiolo@online.microsoft.com> escreveu na
mensagem news:uKihBhFZGHA.3532@TK2MSFTNGP05.phx.gbl...
> The MS C-Runtime implementations offers features such as
> - calling "atexit()" handlers in C++ applications (a `C` feature in C++)

I don't expect to get rid of C++ because I'm a C programmer or otherwise...
C++ is a superset of C.
But... the way I see things, CLR is not a superset of Win32!

> Writing a runtime that fits exactly and all the needs of a specific
> "domain"
> would imply creating an un-necessary complication on the infrastrucutre.
> Immagine linking a C++-but-not-C runtime, a CLR-but-not-C++ runtime,
> a C-but-not-C++ runtime, and explaining people why certain feature
> works (or do not work) as they would legitimately expect.

But there are people still using Win9x and Win2k without .NET Framework in
this world (believe it or not!).
This should be a feature available to the developer (like: not using /clr
switch will NOT put any CLR code in my binary image!).

> If it makes you feel better, since WinXp the NtDll-User-mode loader
> has been modified to recognize the COR+2.0 images, so, even the
> OS is CLR aware.

I didn't know that!!!
Argh!

> The code that possibly invokes CorExitProcess should never be more than
> a few hundreds of bytes of compiled code.

I know... i know... not even 30 bytes of code.... maybe...

> --
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> Use of any included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
>

Hehehe... maybe you can put EULA here!

[]s
Fred

Ken
Fri Apr 21 08:04:17 CDT 2006

Frederico Pissarra wrote:
> But I'm absolute certain that my code is 100% pure and don't use any CLR
> artifacts....
> Try this:
>
> #include <stdio.h>
>
> void main(void) { printf("hello\n"); }
>
> and mscroree.dll and CorExitProcess will be there!

Of course, because it is perfectly legitimate for other parts of the
system to have injected a DLL into your process that might directly
or indirectly use the CLR. You have complete control over your EXE.
You do not have complete control over the process that it runs in.
The end-user, or their administrator, or some part of the operating
system either now or in the future, is perfectly entitled to add bits.

You could certainly argue that it shouldn't be the job of the EXE's
run-time library to invoke such functions. Does anyone know why this
test (for the CLR) is not done as part of ExitProcess()?

Frederico
Fri Apr 21 20:50:14 CDT 2006


"Ken Hagan" <K.Hagan@thermoteknix.co.uk> wrote in message
news:e3ZeaQUZGHA.4936@TK2MSFTNGP05.phx.gbl...
> Frederico Pissarra wrote:
>> But I'm absolute certain that my code is 100% pure and don't use any CLR
>> artifacts....
>> Try this:
>>
>> #include <stdio.h>
>>
>> void main(void) { printf("hello\n"); }
>>
>> and mscroree.dll and CorExitProcess will be there!
>
> Of course, because it is perfectly legitimate for other parts of the
> system to have injected a DLL into your process that might directly
> or indirectly use the CLR. You have complete control over your EXE.
> You do not have complete control over the process that it runs in.
> The end-user, or their administrator, or some part of the operating
> system either now or in the future, is perfectly entitled to add bits.

Ah! I see... thanks!
I didn't thought about DLL injection at all...

>
> You could certainly argue that it shouldn't be the job of the EXE's
> run-time library to invoke such functions. Does anyone know why this
> test (for the CLR) is not done as part of ExitProcess()?

In this scenario changing ExitProcess behavior should be the right approach,
isn't it?

[]s
Fred