Search

Process.GetProcesses by Blue Baron

Closed
as By Design Help for as By Design

1
0
Sign in
 to vote
Type: Bug
ID: 550028
Opened: 4/9/2010 1:37:05 PM
Access Restriction: Public
0
Workaround(s)
0
User(s) can reproduce this bug
The following code leaves behind open resources that prevents an open ipc connection from closing.
            Process[] processList = Process.GetProcesses(this.ResourceName);

            int process_length = processList.Length;

            values = new string[process_length, 2];

            for(int x = 0; x < process_length; x++)
            {
                values[x,0] = processList[x].ProcessName.ToString();
                values[x,1] = processList[x].StartInfo.UserName.ToString();

                processList[x].Close();
            }

            processList = null;
Details (expand)

Product Language

English

Version

Visual Studio 2010 Release Candidate

Operating System

Windows XP

Operating System Language

English

Steps to Reproduce

Make a connection to ipc. Use this code over that connection.

Actual Results

IPC connection cannot close.

Expected Results

IPC connection should be allowed to close.
      You can indicate your satisfaction with how Microsoft handled this issue by completing this quick 3 question survey. [Details]

 

File Attachments
File Name Submitted By Submitted On File Size  
ProcessesIssue.zip Blue Baron 4/15/2010 46 KB
ProcessesIssue.zip Blue Baron 4/15/2010 46 KB
Sign in to post a comment.
Posted by Microsoft on 5/12/2010 at 4:14 PM
Bluebaron,
Thanks for submitting this bug. It turns out this behavior is By Design for performance reasons. It's not the resources you were holding on to from the Process instance, but a Registry reference on the remote machine that is held open so that subsequent calls to GetProcesses on the remote machine will execute faster.

There are two work-around that you can use in your code to release that IPC connection. The first is to call PerformanceCounter.CloseSharedResources() which will release the connection. Note that this will also close out any performance counters you may have open in other parts of the process, but if are not using performance counters elsewhere, this is a good option. The second is to call NetUseDel a second time with the same paramters when the result from the first call is 2401 (ERROR_OPEN_FILES).

Given this information, I'm going to resolve this issue as By Design. If you have any other comments or feedback about this, feel free to either reactivate the bug or contact me directly at chris.szurgot@microsoft.com.

Thanks,
Chris Szurgot
SDET II
Posted by Blue Baron on 4/19/2010 at 1:25 PM
Any news on this one. I can't get help from Microsoft, even though we have MSDN support. I provided an attached file. Did it get through properly? Someone please help.
Posted by Blue Baron on 4/15/2010 at 6:49 AM
If you do get the file, note that when you run the offending process and disconnect without force, it leaves behind that ipc connection. Disconnecting with force works. This is the only open resource issue I cannot resolve out of the 10 or so ipc related calls I have in my actual project.
Posted by Blue Baron on 4/15/2010 at 6:47 AM
I'm trying to attach a file to this but it keeps saying that there isn't a file attached when I'm done. Hope you guys get the file.
Posted by Microsoft on 4/15/2010 at 4:37 AM
Hello Bluebaron,

Sorry for bothering. Is there any update?

It would be greatly appreciated if you could provide us with that information as quickly as possible. If we do not hear back from you within 7 days, we will close this issue.

Thanks again for your efforts and we look forward to hearing from you.

Visual Studio Product Team
Posted by Microsoft on 4/12/2010 at 1:26 AM
Thank you for reporting this issue.
Could you please provide us with a project to help us reproduce this issue?
Sign in to post a workaround.
© 2012 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement