| Groups | Blog | Home |
dotnet interop : Killing an Unmanaged VB6 COM Process from C#
[quoted text, click to view] Christopher G. Carnahan <cgcarnahan@earthlink.net> wrote: >I have a C# service that is making regular calls into an out-of-process COM >component written in VB6. Problem is, if the VB component blocks and >hangs, or goes into an infinite loop (don't ask why, it just does), then I >want to free and release it. > > When I've decided I'm done waiting for the object to return, I call > Thread.Abort on the thread that created the COM object and called the > method that is blocking. But it doesn't look like that thread actually > aborts. > > And of course, the actual process that the component is running in hangs > around, stuck in it's infinite loop. And subsequent Requests for that COM > component will stall forever, right, because the single VB thread is > already consumed by the first infinite loop? > > Does anybody have any ideas? Worst case scenario, I need to identify the > process that the VB6 object is in and kill it. But nothing in the interop > library that I can find will identify that process for me? Am I missing > it? When you create an out-of-process COM object, COM will start the exe file with a command line switch -Embedding or something like that. The exe will then register its class factory in the Running Object Table and COM will use it from there. Now, say you explicitly start the exe file with -Embedding and keep the process handle. The exe will register its class factory in the ROT. After a delay to allow this, you can then create an instance. COM will try the ROT before it tries starting the exe, so it will use the process you just started and you can use the process handle you got to shut it down. Though I'm not sure what happens to the ROT entry if the server process gets terminated without being given a chance to unregister. I don't know if COM will detet it's gone or keep waiting for the resurrection of the dead. It might be possible somehow to make an asynchroneous interrupt and have it unregister the ROT entry... but then again, it might be easier to get the source and slay the bug that makes it hang. (I really don't know a **** about interop and shouldn't be answering questions in this NG, but your problem really seems to be about killing running COM objects more than it has to do with interop. No Off topic-bashing intended.) HTH/ON
I have a C# service that is making regular calls into an out-of-process COM
component written in VB6. Problem is, if the VB component blocks and hangs, or goes into an infinite loop (don't ask why, it just does), then I want to free and release it. When I've decided I'm done waiting for the object to return, I call Thread.Abort on the thread that created the COM object and called the method that is blocking. But it doesn't look like that thread actually aborts. And of course, the actual process that the component is running in hangs around, stuck in it's infinite loop. And subsequent Requests for that COM component will stall forever, right, because the single VB thread is already consumed by the first infinite loop? Does anybody have any ideas? Worst case scenario, I need to identify the process that the VB6 object is in and kill it. But nothing in the interop library that I can find will identify that process for me? Am I missing it? - Christopher
I didn't write the component, I know what the problem is, and changing =
it is not an option (right now). Finding the process and killing it was my plan, but there's no way to = get that information from the COM object or from any .Net framework = classes is there? So I have to write code to take the ProgID, find it = in the registry, locate the associated LocalServr32 file, and hope that = the process name and the .exe name are always the same. No one has any other options? - Christopher "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> wrote = in message news:uiIYr6y3FHA.1276@TK2MSFTNGP09.phx.gbl... [quoted text, click to view] > Christopher,
>=20 > If the program is your own, then you have to find out what is = causing=20 > the loop. Coding around it like this is just going to bring you more=20 > headaches. When you say "don't ask why, it just does", that means = that you=20 > either know what the problem is, and refuse to fix it, or you don't = know=20 > what the problem is. >=20 > Ultimately, there is no excuse for either case. >=20 > Regardless, killing the thread that you made the call on isn't = going to=20 > help. If you are stuck in an interop call, then calling Abort will = not kill=20 > that thread. >=20 > Your best bet would be to find the process using the Process class, = and=20 > once you have an instance of the Process class representing that = process,=20 > call the Kill method on it. >=20 > Hope this helps. >=20 >=20 > --=20 > - Nicholas Paldino [.NET/C# MVP] > - mvp@spam.guard.caspershouse.com >=20 > "Christopher G. Carnahan" <cgcarnahan@earthlink.net> wrote in message=20 > news:eFfVyxy3FHA.1396@TK2MSFTNGP12.phx.gbl... >>I have a C# service that is making regular calls into an = out-of-process COM=20 >>component written in VB6. Problem is, if the VB component blocks and=20 >>hangs, or goes into an infinite loop (don't ask why, it just does), = then I=20 >>want to free and release it. >> >> When I've decided I'm done waiting for the object to return, I call=20 >> Thread.Abort on the thread that created the COM object and called the = >> method that is blocking. But it doesn't look like that thread = actually=20 >> aborts. >> >> And of course, the actual process that the component is running in = hangs=20 >> around, stuck in it's infinite loop. And subsequent Requests for = that COM=20 >> component will stall forever, right, because the single VB thread is=20 >> already consumed by the first infinite loop? >> >> Does anybody have any ideas? Worst case scenario, I need to identify = the=20 >> process that the VB6 object is in and kill it. But nothing in the = interop=20 >> library that I can find will identify that process for me? Am I = missing=20 >> it? >> >> - Christopher >> >> >>=20 >=20
There's more than 1 component with this problem. I need to find out =
dynamically what the name of the process is. - CGC "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> = [quoted text, click to view] wrote in message news:u7K4AGz3FHA.4076@TK2MSFTNGP15.phx.gbl... Christopher, Did you look at the Process class? When your component is = running, it has a process name in the Task Manager. Just find out what = it is and then use the Process class to get the managed representation = of it and then kill it. --=20 - Nicholas Paldino [.NET/C# MVP] - mvp@spam.guard.caspershouse.com "Christopher G. Carnahan" <cgcarnahan@earthlink.net> wrote in = message news:O1rwl%23y3FHA.3592@TK2MSFTNGP12.phx.gbl... I didn't write the component, I know what the problem is, and = changing it is not an option (right now). Finding the process and killing it was my plan, but there's no way = to get that information from the COM object or from any .Net framework = classes is there? So I have to write code to take the ProgID, find it = in the registry, locate the associated LocalServr32 file, and hope that = the process name and the .exe name are always the same. No one has any other options? - Christopher "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> = [quoted text, click to view] wrote in message news:uiIYr6y3FHA.1276@TK2MSFTNGP09.phx.gbl...
> Christopher, >=20 > If the program is your own, then you have to find out what is = causing=20 > the loop. Coding around it like this is just going to bring you = more=20 > headaches. When you say "don't ask why, it just does", that means = that you=20 > either know what the problem is, and refuse to fix it, or you = don't know=20 > what the problem is. >=20 > Ultimately, there is no excuse for either case. >=20 > Regardless, killing the thread that you made the call on isn't = going to=20 > help. If you are stuck in an interop call, then calling Abort = will not kill=20 > that thread. >=20 > Your best bet would be to find the process using the Process = class, and=20 > once you have an instance of the Process class representing that = process,=20 > call the Kill method on it. >=20 > Hope this helps. >=20 >=20 > --=20 > - Nicholas Paldino [.NET/C# MVP] > - mvp@spam.guard.caspershouse.com >=20 > "Christopher G. Carnahan" <cgcarnahan@earthlink.net> wrote in = message=20 > news:eFfVyxy3FHA.1396@TK2MSFTNGP12.phx.gbl... >>I have a C# service that is making regular calls into an = out-of-process COM=20 >>component written in VB6. Problem is, if the VB component blocks = and=20 >>hangs, or goes into an infinite loop (don't ask why, it just = does), then I=20 >>want to free and release it. >> >> When I've decided I'm done waiting for the object to return, I = call=20 >> Thread.Abort on the thread that created the COM object and called = the=20 >> method that is blocking. But it doesn't look like that thread = actually=20 >> aborts. >> >> And of course, the actual process that the component is running = in hangs=20 >> around, stuck in it's infinite loop. And subsequent Requests for = that COM=20 >> component will stall forever, right, because the single VB thread = is=20 >> already consumed by the first infinite loop? >> >> Does anybody have any ideas? Worst case scenario, I need to = identify the=20 >> process that the VB6 object is in and kill it. But nothing in = the interop=20 >> library that I can find will identify that process for me? Am I = missing=20 >> it? >> >> - Christopher >> >> >>=20 >=20
Christopher,
If the program is your own, then you have to find out what is causing the loop. Coding around it like this is just going to bring you more headaches. When you say "don't ask why, it just does", that means that you either know what the problem is, and refuse to fix it, or you don't know what the problem is. Ultimately, there is no excuse for either case. Regardless, killing the thread that you made the call on isn't going to help. If you are stuck in an interop call, then calling Abort will not kill that thread. Your best bet would be to find the process using the Process class, and once you have an instance of the Process class representing that process, call the Kill method on it. Hope this helps. -- - Nicholas Paldino [.NET/C# MVP] - mvp@spam.guard.caspershouse.com [quoted text, click to view] "Christopher G. Carnahan" <cgcarnahan@earthlink.net> wrote in message news:eFfVyxy3FHA.1396@TK2MSFTNGP12.phx.gbl... >I have a C# service that is making regular calls into an out-of-process COM >component written in VB6. Problem is, if the VB component blocks and >hangs, or goes into an infinite loop (don't ask why, it just does), then I >want to free and release it. > > When I've decided I'm done waiting for the object to return, I call > Thread.Abort on the thread that created the COM object and called the > method that is blocking. But it doesn't look like that thread actually > aborts. > > And of course, the actual process that the component is running in hangs > around, stuck in it's infinite loop. And subsequent Requests for that COM > component will stall forever, right, because the single VB thread is > already consumed by the first infinite loop? > > Does anybody have any ideas? Worst case scenario, I need to identify the > process that the VB6 object is in and kill it. But nothing in the interop > library that I can find will identify that process for me? Am I missing > it? > > - Christopher > > >
Christopher,
Did you look at the Process class? When your component is running, = it has a process name in the Task Manager. Just find out what it is and = then use the Process class to get the managed representation of it and = then kill it. --=20 - Nicholas Paldino [.NET/C# MVP] - mvp@spam.guard.caspershouse.com [quoted text, click to view] "Christopher G. Carnahan" <cgcarnahan@earthlink.net> wrote in message = I didn't write the component, I know what the problem is, and changing =news:O1rwl%23y3FHA.3592@TK2MSFTNGP12.phx.gbl... it is not an option (right now). Finding the process and killing it was my plan, but there's no way to = get that information from the COM object or from any .Net framework = classes is there? So I have to write code to take the ProgID, find it = in the registry, locate the associated LocalServr32 file, and hope that = the process name and the .exe name are always the same. No one has any other options? - Christopher "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> = [quoted text, click to view] wrote in message news:uiIYr6y3FHA.1276@TK2MSFTNGP09.phx.gbl...
> Christopher, >=20 > If the program is your own, then you have to find out what is = causing=20 > the loop. Coding around it like this is just going to bring you = more=20 > headaches. When you say "don't ask why, it just does", that means = that you=20 > either know what the problem is, and refuse to fix it, or you don't = know=20 > what the problem is. >=20 > Ultimately, there is no excuse for either case. >=20 > Regardless, killing the thread that you made the call on isn't = going to=20 > help. If you are stuck in an interop call, then calling Abort will = not kill=20 > that thread. >=20 > Your best bet would be to find the process using the Process = class, and=20 > once you have an instance of the Process class representing that = process,=20 > call the Kill method on it. >=20 > Hope this helps. >=20 >=20 > --=20 > - Nicholas Paldino [.NET/C# MVP] > - mvp@spam.guard.caspershouse.com >=20 > "Christopher G. Carnahan" <cgcarnahan@earthlink.net> wrote in = message=20 > news:eFfVyxy3FHA.1396@TK2MSFTNGP12.phx.gbl... >>I have a C# service that is making regular calls into an = out-of-process COM=20 >>component written in VB6. Problem is, if the VB component blocks = and=20 >>hangs, or goes into an infinite loop (don't ask why, it just does), = then I=20 >>want to free and release it. >> >> When I've decided I'm done waiting for the object to return, I call = >> Thread.Abort on the thread that created the COM object and called = the=20 >> method that is blocking. But it doesn't look like that thread = actually=20 >> aborts. >> >> And of course, the actual process that the component is running in = hangs=20 >> around, stuck in it's infinite loop. And subsequent Requests for = that COM=20 >> component will stall forever, right, because the single VB thread = is=20 >> already consumed by the first infinite loop? >> >> Does anybody have any ideas? Worst case scenario, I need to = identify the=20 >> process that the VB6 object is in and kill it. But nothing in the = interop=20 >> library that I can find will identify that process for me? Am I = missing=20 >> it? >> >> - Christopher >> >> >>=20 >=20
[quoted text, click to view]
"Christopher G. Carnahan" <cgcarnahan@earthlink.net> wrote in message news:eFfVyxy3FHA.1396@TK2MSFTNGP12.phx.gbl... >I have a C# service that is making regular calls into an out-of-process COM >component written in VB6. Problem is, if the VB component blocks and >hangs, or goes into an infinite loop (don't ask why, it just does), then I >want to free and release it. > > When I've decided I'm done waiting for the object to return, I call > Thread.Abort on the thread that created the COM object and called the > method that is blocking. But it doesn't look like that thread actually > aborts. > > And of course, the actual process that the component is running in hangs > around, stuck in it's infinite loop. And subsequent Requests for that COM > component will stall forever, right, because the single VB thread is > already consumed by the first infinite loop? > > Does anybody have any ideas? Worst case scenario, I need to identify the > process that the VB6 object is in and kill it. But nothing in the interop > library that I can find will identify that process for me? Am I missing > it? > > - Christopher > > > You do know the .exe file name of the VB6 ActiveX server program do you? So, you can use System.Diagnostics.Process.GetProcessByName(the.exe name) to get the corresponding Process instance and kill that one using Process.Kill. Note that it might be possible that you can't kill the process because you haven't sufficient privileges to do so. Also note that you should not call Thread.Abort at all, chances are that you are corrupting your process state, just reinitiate the client process, or use a separate Application Domain to run the COM client, when the server hangs you simply throw away the offending AD and create a new one to restart the client. Willy.
I suppose that each components is "hosted" in a differently named .exe =
file, so it' should be possible to associate the component with the .exe = and kill that one as explained previously. However, if your components = are "hosted" in .exe files each having the same name, you're stuck. Willy. [quoted text, click to view] "Christopher G. Carnahan" <cgcarnahan@earthlink.net> wrote in message = There's more than 1 component with this problem. I need to find out =news:uFMr5Hz3FHA.2432@TK2MSFTNGP10.phx.gbl... dynamically what the name of the process is. - CGC "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> = [quoted text, click to view] wrote in message news:u7K4AGz3FHA.4076@TK2MSFTNGP15.phx.gbl... Christopher, Did you look at the Process class? When your component is = running, it has a process name in the Task Manager. Just find out what = it is and then use the Process class to get the managed representation = of it and then kill it. --=20 - Nicholas Paldino [.NET/C# MVP] - mvp@spam.guard.caspershouse.com "Christopher G. Carnahan" <cgcarnahan@earthlink.net> wrote in = message news:O1rwl%23y3FHA.3592@TK2MSFTNGP12.phx.gbl... I didn't write the component, I know what the problem is, and = changing it is not an option (right now). Finding the process and killing it was my plan, but there's no way = to get that information from the COM object or from any .Net framework = classes is there? So I have to write code to take the ProgID, find it = in the registry, locate the associated LocalServr32 file, and hope that = the process name and the .exe name are always the same. No one has any other options? - Christopher "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> = [quoted text, click to view] wrote in message news:uiIYr6y3FHA.1276@TK2MSFTNGP09.phx.gbl...
> Christopher, >=20 > If the program is your own, then you have to find out what is = causing=20 > the loop. Coding around it like this is just going to bring you = more=20 > headaches. When you say "don't ask why, it just does", that = means that you=20 > either know what the problem is, and refuse to fix it, or you = don't know=20 > what the problem is. >=20 > Ultimately, there is no excuse for either case. >=20 > Regardless, killing the thread that you made the call on = isn't going to=20 > help. If you are stuck in an interop call, then calling Abort = will not kill=20 > that thread. >=20 > Your best bet would be to find the process using the Process = class, and=20 > once you have an instance of the Process class representing that = process,=20 > call the Kill method on it. >=20 > Hope this helps. >=20 >=20 > --=20 > - Nicholas Paldino [.NET/C# MVP] > - mvp@spam.guard.caspershouse.com >=20 > "Christopher G. Carnahan" <cgcarnahan@earthlink.net> wrote in = message=20 > news:eFfVyxy3FHA.1396@TK2MSFTNGP12.phx.gbl... >>I have a C# service that is making regular calls into an = out-of-process COM=20 >>component written in VB6. Problem is, if the VB component = blocks and=20 >>hangs, or goes into an infinite loop (don't ask why, it just = does), then I=20 >>want to free and release it. >> >> When I've decided I'm done waiting for the object to return, I = call=20 >> Thread.Abort on the thread that created the COM object and = called the=20 >> method that is blocking. But it doesn't look like that thread = actually=20 >> aborts. >> >> And of course, the actual process that the component is running = in hangs=20 >> around, stuck in it's infinite loop. And subsequent Requests = for that COM=20 >> component will stall forever, right, because the single VB = thread is=20 >> already consumed by the first infinite loop? >> >> Does anybody have any ideas? Worst case scenario, I need to = identify the=20 >> process that the VB6 object is in and kill it. But nothing in = the interop=20 >> library that I can find will identify that process for me? Am = I missing=20 >> it? >> >> - Christopher >> >> >>=20 >=20
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |