Handle leak (ALPC port) when using CreateObject() to create reference to a COM object

Question

Hi there,

I am supporting a legacy VB6 system. I recently discover a handle leak appears caused by using the CreateObject() to create  and return a reference to a COM object. This handle leak type is shown as “ALPC  port” at the Process Explorer. I had tried to exit the COM object from my reference and set the reference to Nothing at my code, but this handle did not got destroyed . Although this handle looks timeout and eventually exit itself, I would like to know if anyone of you have better resolution. Please post here if you have experience of this, or knowing what is the cause and fix of this problem.   My OS are windows server 2008 R1 and Windows 7 SP1.

Here is a sample of my testing code:

Dim testExcel As Object
Dim testWord As Object  
Private Sub Form_Load()    
	Set testExcel = CreateObject("Excel.Application")    
	Set testWord = CreateObject("Word.Application")
End Sub 
Private Sub Form_Unload(Cancel As Integer)    
	If Not testExcel Is Nothing Then testExcel.Quit    
	Set testExcel = Nothing       
	If Not testWord Is Nothing Then testWord.Quit    
	Set testWord = Nothing
End Sub

  

Note:

• From the process explorer, You could observe the “ALPC  port” persists in the memory if you put a breakpoint at the end of the Form_Unlod method.
• The problem seems to happen when the COM object is complied as executable, DLL is fine.
• I tried both early binding and late binding, but it didn’t help to solve the problem.

Thank you for your help!

Simon

Answer 1

An out of process ActiveX component is correctly unloaded when all of the following coditions are met

A : The variables in a client app that point to objects in the server have been set to nothing explicitly or implicitly because they went out of scope

B: No Request is in the queu for the server object waiting to be served

C: The server has no form currently loaded ( vissible or invissible )

D: The server isn`t executing anny code

Note  if you used a workbook  in excel etc etc you need to close it first

Another common mistake in VB6 is that people write code in the forms terminate event that refernce the form or one of its controls from code  in that case Visual basic doesn`t raise an error but it silently creates a new instance of that form wich silently remains hidden in memory  .

HTH

Michel Posseth   

 

---

My Code gallery contributions
My site
My Linkedin Profile

Answer 2

Simon,

I'm glad that Michel was able to help, but this isn't a VB 6 forum.

---

Please call me Frank :)

Answer 3

Hi Frank, thank you for point this out. Could you please let me know where I can post the VB6 questions?

Simon

Answer 4

Hi Frank, thank you for point this out. Could you please let me know where I can post the VB6 questions?

Simon

Well, about the only ones that I'm aware of are from the link at the top of this forum.

---

Please call me Frank :)

Answer 5

Hi Michel, thanks for your reply.

I had checked every bullet you listed above, but I don’t have any luck to resolve my problem. I used a very simple workbook program to show my problem as an example. I also did close (quit) the workbook app before I set the reference to nothing in my example.

The handle leak is not obvious; a very small number of leaks per VB6 form. From the Process Explorer, I can see the ALPC ports accumulating because of this handle leak (Other resources had been cleaned up except this).

I know this leak does not cause a lot of problem to my system, but I would like to confirm if that is my coding problem or it is a vb6 run-time issue.

Thanks again,

Simon

Answer 6

Thanks!

Answer 7

Well if you followed the general guidelines and the instances of the COM servers dissapear from the process list then you did your job fine

I have just performed a test in VB.Net 2010 with late binding and the Sysinternals process explorer and noticed that there the same thing happens my app is closed but it takes numerous seconds an refreshes of the view before the ALPC process dissapears

note you do not see this in the "standard" process explorer of windows it is hidden by the OS so you need to use the "special" under the hood explorer you can get it from technet

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

If you do your VB.Net / C# test just search on ALPC and you will notice the 2 processes for your late bound instances.

So IMO the only difference between VB6 and .Net is that  that .Net just hides the low levell  operating system stuff  

A  quick google learns that ALPC actually works with timeouts so i guess it is expected behavior

---

My Code gallery contributions
My site
My Linkedin Profile

Answer 8

Well if you followed the general guidelines and the instances of the COM servers dissapear from the process list then you did your job fine

I have just performed a test in VB.Net 2010 with late binding and the Sysinternals process explorer and noticed that there the same thing happens my app is closed but it takes numerous seconds an refreshes of the view before the ALPC process dissapears

note you do not see this in the "standard" process explorer of windows it is hidden by the OS so you need to use the "special" under the hood explorer you can get it from technet

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

If you do your VB.Net / C# test just search on ALPC and you will notice the 2 processes for your late bound instances.

So IMO the only difference between VB6 and .Net is that  that .Net just hides the low levell  operating system stuff  

A  quick google learns that ALPC actually works with timeouts so i guess it is expected behavior

---

My Code gallery contributions
My site
My Linkedin Profile

Hi Michel, thanks for your time and your confirmation of the ALPC behavior.

Simon