vbscript and COM+ apps

Tom Dunne

Don't know if this should be in Windows or programming, so I'll give it a go here.

I have a COM+ app that is hogging the CPU (all 8 of them ) an bringing down a system. Problem is, we can't figure out which COM+ app it is (there are over 200 on the system).

I am writing a VBscript to write to a log file the COM+ app name, it's associated dllhost.exe and most importantly, the PID. The last two parts are easy enough - the bit I am having trouble with is finding the PID of the COM+ app.

Anyone got any ideas/pointers?

Thanks,

TD.

ressem

What are you using to get the appname, would have thought that you'd be using Win32_Process
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/win32_process.asp
in which case ProcessID should be what you're looking for
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/wmi_tasks__processes.asp

Or there's
http://www.sysinternals.com/ntw2k/freeware/pslist.shtml
which can be called from a redmote PC.

Tom Dunne

ressem wrote:

What are you using to get the appname, would have thought that you'd be using Win32_Process

Yes, I am and therin lies the problem - COM+ apps run under dllhost.exe, so when I use the above, I only get the PID of dllhost.exe (all 200 or so of them). I am looking for something to link the COM+ app to a specific dllhost.exe, so I can figure out the PID.

ressem

So you're seeing a particular DLLHOST taking up all the CPU. You have it's PID from task manager. If you get a list of command line used to run DLLHOSTs + PID you'll have all the informartion you need to identify the application?

You should be able to get this information by logging the win32_process's "command line" property + ProcessID + kernelmodetime + usermodetime.

Easiest way, if the gui is responding at all
using process explorer from sysinternals.com (properties/image)shows, for example on my machine, the command line of a rundll.exe process to be

rundll32 nView.dll,nViewInitialize

and the threads to be

rundll.exe + 0xaddress
nview.dll + 0xaddress
kernel32.dll + 0xaddress
nview.dll + 0xaddress

Edit-- D'oh. not what you ware asking mixed up dllhost with rundll. rush of blood to the head --

-- Edit 2 --
but the command line does provide the application ID suitable for looking up in component services.

\WINNT\system32\dllhost.exe /Processid:{02D4B3F1-FD88-11D1-960D-00805FC79235}

Tom Dunne

Hmmm, you could be onto something with the command line thingy.

On the GUI - these problems usually happen out of hours, with the server grinding to a halt, so there is generally no option other than rebooting the server. Hence the need to create a script to write to a log file so I can have a look at it during normal office hours.

amen

what language are your Com+ dlls written in ?
if vb have you checked out

http://support.microsoft.com/default.aspx?id=kb;en-us;Q286036

are your dlls installed as packages in Com +
if once you have the pid ( should be able to find it on Task Manager)
go to Com+ and open the relevant package. You may be able to find the dll/class that is causing the problme

Have you check you event logs ?
Is there DB access involved ?

What sort of application is it ?

Tom Dunne

amen wrote:

what language are your Com+ dlls written in ?

Erm, I think you may have mis-read the my initial post. The COM+ apps run under the dllhost.exe wrapper. I am not really sure what language they are written, I assume VB.

amen wrote:

are your dlls installed as packages in Com +
if once you have the pid ( should be able to find it on Task Manager)
go to Com+ and open the relevant package. You may be able to find the dll/class that is causing the problme

Again, these problems occur in the middle of the night. The system becomes completely unresponsive, so going to task manager and the like is not really an option.

Also, Componet Services gives the PID, that's not the problem here.

amen wrote:

Have you check you event logs ?
Is there DB access involved ?

What sort of application is it ?

Yes, I have checked the Event Logs, nothing in there, and yes there is DB access for some of them.

The overall application subscribes to TIB Rendezvous published messages (in a distributed environment, of course) a custom component converts the TIB messages into XML, sends them to MSMQ, where these COM+ components pick them up and send them to a remote database.

amen

well if they are written in vb you really should use the vbchkw2k file and do what the knowledge base articles suggest
where are you based ? (not Galway by any chance ?)
what company ?

Tom Dunne

amen wrote:

where are you based ? (not Galway by any chance ?)

No, not Galway, much further East.

amen wrote:

what company ?

Search around, it shouldn't be too hard to work it out.