Console exe continues to run after exiting all of my code

[Tim Werth]

I have a .NET console application that is kicked off by a .NET Windows
service. They communicate via .NET Remoting, although there isn't much
communication between the two while the console app is running. There can
be, and are typically, several instances of the console app running at the
same time communicating back to the service.

The console app creates a delegate to do some work while the main thread
waits on a ManualResetEven t to be signaled (ManualResetEve nt.WaitOne()).
When the delegate is done, it calls Set on the ManualResetEven t, the WaitOne
returns and the app exits - 99.99999% of the time.

This is very hard to reproduce, but every once in a while, once the console
app has finished running all of the code I put in it, but it continues to run
- and at 45-50% of the CPU. Here is my Main:

[STAThread]
static void Main(string[] args)
{
try
{
// Create the one and only TsDPDllHost class for this process
WriteTrace( "1 Creating object" );
MyClass myClass = new MyClass);
WriteTrace( "2 calling myClass.Run" );
myClass.Run();
WriteTrace( "3 Exiting" );
}
catch(Exception e)
{
WriteTrace( "4 Exiting - ERROR e.Message=" + e.Message );
}
}

No exceptions are thrown and the trace statements #1, 2, and 3 are written
to a log file. TaskManager says the console app has 1 thread left, but
trying to attach to it with a debugger never comes back. Using SysInternals'
Process Explorer shows the following as the stack on the 1 thread:

ntdll.dll!RtlFr eeHeap+0x67
!TipUnloadProje ct+0xc2d
!TipUnloadProje ct+0xba7
!TipUnloadProje ct+0x741
!BASIC_DISPINTE RFACE_GetTICoun t+0xd5bf
ntdll.dll!LdrIn itializeThunk+0 x29
ntdll.dll!LdrSh utdownProcess+0 x142
!IsValidLocale+ 0x8eb
!ExitProcess+0x 14
!GetCompileInfo +0x6553c
!CorExeMain+0x7 9
!RegisterWaitFo rInputIdle+0x49

Has anybody seen anything like this or know what might be going on?

Thanks,
Tim

[Yan-Hong Huang[MSFT]]

Hello Tim,

From the problem description, it is hard to isolate the problem without
detailed debug information. I suggest you create more trace information in
the application to write down the console application process ID and thread
ID.

Besides, is the windows service always running well?

Another troubleshooting way is try to simply your console application as
much as possible to isolate which part the problem exists.

By the way, please refer to the follow topic on how to debug your windows
service application:
http://msdn.microsoft.com/library/de...us/vbcon/html/
vbtskdebuggings erviceapplicati ons.asp
It may also be helpful for this scenario.

Generally speaking, this kind of problem (hard to repro) is better to be
troubleshooted by debugging tools. But let us try the above ways first to
see whether we can get some more information first.

Thanks very much.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
http://msdn.microsoft.com/subscripti...gednewsgroups/

This posting is provided "AS IS" with no warranties, and confers no rights.

[Tim Werth]

Yan-Hong,

Thank you for your response. I am sorry it has taken me so long to get back
to this. I have done what you suggested and the main thread is what is
hanging. The Windows service is always running, but it is functioning
normally. It is a child process of that service that is hanging in its main
thread. The stack trace this time is:

ntdll.dll!strch r+0x101
ntdll.dll!RtlIn itializeSListHe ad+0x2ee0
!TipUnloadProje ct+0xc2d
!TipUnloadProje ct+0xba7
!TipUnloadProje ct+0x741
!BASIC_DISPINTE RFACE_GetTICoun t+0xd5bf
ntdll.dll!LdrIn itializeThunk+0 x29
ntdll.dll!LdrSh utdownProcess+0 x142
!IsValidLocale+ 0x8eb
!ExitProcess+0x 14
!GetCompileInfo +0x6553c
!CorExeMain+0x7 9
!RegisterWaitFo rInputIdle+0x49

From the stack trace, it looks like it is out of all my code and is trying
to shutdown the process. I have tried attaching to the process using VS.NET
2003's debugger, but after selecting the process, control is never returned
to the IDE.

Yes, I agree it is better to use debugging tools, but when the debugger
doesn't come back, it is kind of hard. Are there any other suggestions or
debugging tools I could use?

[Jeffrey Tan[MSFT]]

Hi ecydba,

Thanks for your feedback.

Actually, I am confused by your statement. Let's do some scoping first:

You have several console .Net applications may communicate with single .Net
windows service application through .Net Remoting. You console application
main thread use a threadpool asynchronized delegate to do the background
processing(at the meantime, the main console thread wait and sleep on a
ManualResetEven t). After the background delegate thread finished all the
work, it set the ManualResetEven t, which wake up the main console thread
and the application runs through all the code and exits. But, sometimes,
you find the console application did not exit at all. If I have
misunderstood you, please feel free to let me know.

Regarding this scenario, there are 2 threads in your console application,
main GUI thread and threadpool background delegate thread.

I have done what you suggested and the main thread is what is
hanging. Can you confirm the "main thread" you are referring is console application
"main thread" or .Net service application "main thread"?
It is a child process of that service that is hanging in its main
thread.

I am confused by this statement. In your first post, you did not memtion
any child process. So we need some context information regarding this child
process. Also, can you confirm whether the hang lies in the client console
application or certain child process main thread?

At last, in call stack, for each stack frame, in front of the "!" there
should be a module name. But in the call stack you listed, there are
certain stack frame without any module name listed. Can you give it a
check?

Thanks!

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Tim Werth]

Your synopsis is correct, except for the fact that in my original post, I
mentioned the .NET service kicks off/creates/spawns the .NET console app,
which I consider a child app.

Regarding this scenario, there are 2 threads in your console application,
main GUI thread and threadpool background delegate thread.
That is correct.

I have done what you suggested and the main thread is what is
hanging.

Can you confirm the "main thread" you are referring is console application
"main thread" or .Net service application "main thread"?

I confirmed it is the main thread of the console app. There is nothing
wrong with the .NET service app.

It is a child process of that service that is hanging in its main
thread.

I am confused by this statement. In your first post, you did not memtion
any child process. So we need some context information regarding this child
process. Also, can you confirm whether the hang lies in the client console
application or certain child process main thread?

The .NET service spawns the (child) .NET console apps. The hang is in the
client (child) console app's main thread.
At last, in call stack, for each stack frame, in front of the "!" there
should be a module name. But in the call stack you listed, there are
certain stack frame without any module name listed. Can you give it a
check?

The frame stack I posted is all I can get from Process Explorer
(procexp.exe/SysInternals). When I try to attach to the child console app
process with VS.NET 2003 debugger, control is never returned to me. So I am
never given a chance to hit the BREAK button to break execution of the app to
see what kind of stack trace VS.NET would give. I have also tried using
Windbg to attach to the process but basically have the same results. When I
key in any of the commands to display the call stack ('k', 'kb', 'kp', 'kv',
'kd'), it says it can't. Sending a break command in windbg times out. So,
the best I can give you is what procexp have given me. If you know of a
better way, I will be happy to try it.

Thanks,
Tim

[Jeffrey Tan[MSFT]]

Hi Tim,

Thanks for your feedback.

Yes, with your further feedback I understand your problem context much
better now.

First, I have some questions regarding your issue: what account your
service is running under? Because it invokes the console application, the
console application should run under the same account as the service. So I
am curious about the session&winstat ion information your console
application was associated with. You can use "Session Viewer" writen by
"Keith Brown" to get the session and winstation information, which can be
downloaded in the link below:
http://www.develop.com/technology/re...42b-504f-4959-
9e18-332848ebfb74

Based on the call stack, your main thread hangs in the ExitProcess API
calling.

Currently, I am not sure why the windbg can not dump out the call stack for
the main thread. Maybe we should use ADPlus to obtain a hang dump of the
console application.

After getting the dump file, you can use windbg to load it and analysis it.

Hope this helps!

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.