Handle leaks?

Has anyone seen handle leaks in ODP.NET? I have a multi-threaded server application that contains managed and unmanaged C++ code and uses ODP.NET. It leaks handles that seem to be thread handles created by ODP.NET. I cannot reproduce it in a simple test. I am working on it, but it would be nice to know if anyone noticed the same problem and has a workaround or fix. This is a big problem in my app because the number of handles goes up to 10,000 in a couple of hours. GC.Collect does not help.
Thanks,
Aleksey

Yes, I know that. I do close and dispose everything. The behaviour is hard to reproduce, but it does happen.
One quick tip you can try is to explicitly close all
objects you created when no longer needed. For
example, call the Close/Dispose method on your your
ODP.NET connections, DataReaders, etc. objects before
you leave your applications scope. Sometimes the
.NET garbage collector cannot reclaim resources
quickly enough under heavily-loaded conditions.
Alex

Similar Messages

Handle leak - Crystal for VS 2010

I've been playing with the Crystal VS2010 runtime and have come across a problem which I believe might be a handle-leak in Crystal Reports.
I can reproduce this at will using the following example:
I created a project with a typed dataset (containing 2 empty tables with only a single column each). I then added a blank report to the project and only added a single text object to it - no data is loaded from the dataset at all.
Then, I can execute the following 100 times in a loop:
using (DataSet1 dataSet = new DataSet1())
   using (CrystalReport1 report = new CrystalReport1())
      report.SetDataSource(dataSet);
      report.Close();
   dataSet.Clear();
This I then follow with a forced garbage collect, just to make sure everything was cleaned up properly. However, +- 100 new handles were opened and using sysinternals' handle.exe, these show up as Mutexes e.g.:
1324: Mutant        \Sessions\1\BaseNamedObjects\CrystalReportXalanInitilizeMutex2916l
I haven't been able to find any information about this on the forums or the internet - can anyone confirm if this is a known issue? (Or am I doing something stupid? )
Thanks!

Hi,
I've tried some of your suggestions:
In you report check on No Printer and check off all o f the Verify Database options. - Made no difference
Also, be sure to use the Legacy mode in your app.config file, search for it. MS issue with DataSets. - Also, no difference
GDI Objects - These don't budge - this is a Mutex leak, not a GDI leak
As for datasets, I'm not filling the dataset - its empty. So a database does not enter into the equation, and no database connection handles are therefore ever created.
Also, I tried the printer theory by running the app on a machine without any printers installed - the problem persisted. Machines also have entirely different graphics card drivers, so highly unlikely to cause the problem.
I've also tried targeting both Framework 4.0 and Framework 2.0 - the leak occurs in both cases.
The code that I posted was only a snippet yes, but it really is 90% of the test-app. This is the whole content of Form1.cs (a single-button form):
using System;
using System.Windows.Forms;
namespace CrystalLeakTest
    public partial class Form1 : Form
        public Form1()
            InitializeComponent();
        private void ProduceReport()
            using (DataSet1 dataSet = new DataSet1())
                using (CrystalReport1 report = new CrystalReport1())
                    report.SetDataSource(dataSet);
                    report.Close();
                dataSet.Clear();
        private void button2_Click(object sender, EventArgs e)
            for (int i = 0; i < 100; i++)
                ProduceReport();
            GC.Collect();
            GC.WaitForPendingFinalizers();
            GC.Collect();
            MessageBox.Show("Done");
The rest of the app is simply a blank report, a blank typed dataset (with 1 table and 1 column - no data). That really is it
Is there anything else I can try?
Thanks!

Registry handles leaked from

+
System
Provider
[ Name]
Microsoft-Windows-User Profiles Service
[ Guid]
{89B1E9F0-5AFF-44A6-9B44-0A07A7CE5845}
[ EventSourceName]
profsvc
EventID
1530
[ Qualifiers]
32768
Version
0
Level
3
Task
0
Opcode
0
Keywords
0x80000000000000
TimeCreated
[ SystemTime]
2011-06-11T07:37:12.000Z
EventRecordID
127007
Correlation
Execution
[ ProcessID]
0
[ ThreadID]
0
Channel
Application
Computer
Panther-PC
Security
[ UserID]
S-1-5-18
EventData
Detail
16 user registry handles leaked from \Registry\User\S-1-5-21-1082989139-2594333343-3947924465-1001: Process 2384 (\Device\HarddiskVolume1\Program Files\Common Files\microsoft shared\Windows Live\WLIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1082989139-2594333343-3947924465-1001
Process 2384 (\Device\HarddiskVolume1\Program Files\Common Files\microsoft shared\Windows Live\WLIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1082989139-2594333343-3947924465-1001 Process 2384 (\Device\HarddiskVolume1\Program Files\Common Files\microsoft
shared\Windows Live\WLIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1082989139-2594333343-3947924465-1001 Process 2384 (\Device\HarddiskVolume1\Program Files\Common Files\microsoft shared\Windows Live\WLIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1082989139-2594333343-3947924465-1001
Process 828 (\Device\HarddiskVolume1\Program Files\NVIDIA Corporation\nTune\nTuneService.exe) has opened key \REGISTRY\USER\S-1-5-21-1082989139-2594333343-3947924465-1001 Process 2384 (\Device\HarddiskVolume1\Program Files\Common Files\microsoft shared\Windows
Live\WLIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1082989139-2594333343-3947924465-1001\Software\Microsoft\SystemCertificates\My Process 2384 (\Device\HarddiskVolume1\Program Files\Common Files\microsoft shared\Windows Live\WLIDSVC.EXE) has opened key
\REGISTRY\USER\S-1-5-21-1082989139-2594333343-3947924465-1001\Software\Microsoft\SystemCertificates\CA Process 2384 (\Device\HarddiskVolume1\Program Files\Common Files\microsoft shared\Windows Live\WLIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1082989139-2594333343-3947924465-1001\Software\Microsoft\SystemCertificates\Root
Process 2384 (\Device\HarddiskVolume1\Program Files\Common Files\microsoft shared\Windows Live\WLIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1082989139-2594333343-3947924465-1001\Software\Microsoft\SystemCertificates\SmartCardRoot Process 2384 (\Device\HarddiskVolume1\Program
Files\Common Files\microsoft shared\Windows Live\WLIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1082989139-2594333343-3947924465-1001\Software\Microsoft\SystemCertificates\TrustedPeople Process 2384 (\Device\HarddiskVolume1\Program Files\Common Files\microsoft
shared\Windows Live\WLIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1082989139-2594333343-3947924465-1001\Software\Microsoft\SystemCertificates\trust Process 2384 (\Device\HarddiskVolume1\Program Files\Common Files\microsoft shared\Windows Live\WLIDSVC.EXE)
has opened key \REGISTRY\USER\S-1-5-21-1082989139-2594333343-3947924465-1001\Software\Policies\Microsoft\SystemCertificates Process 2384 (\Device\HarddiskVolume1\Program Files\Common Files\microsoft shared\Windows Live\WLIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1082989139-2594333343-3947924465-1001\Software\Policies\Microsoft\SystemCertificates
Process 2384 (\Device\HarddiskVolume1\Program Files\Common Files\microsoft shared\Windows Live\WLIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1082989139-2594333343-3947924465-1001\Software\Policies\Microsoft\SystemCertificates Process 2384 (\Device\HarddiskVolume1\Program
Files\Common Files\microsoft shared\Windows Live\WLIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1082989139-2594333343-3947924465-1001\Software\Policies\Microsoft\SystemCertificates Process 2384 (\Device\HarddiskVolume1\Program Files\Common Files\microsoft
shared\Windows Live\WLIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1082989139-2594333343-3947924465-1001\Software\Microsoft\SystemCertificates\Disallowed
should i be worried or can i get some help with this ?

I'm having the same problem on one of work's Server 2008 R2 machines, but the software causing the leaks are the Microsoft Windows programs
cmd.exe
robocopy.exe
conhost.exe
Microsoft can you please stop your software from leaking, thank you.
From the event viewer
Windows detected your registry file is still in use by other applications or services. The file will be unloaded now. The applications or services that hold your registry file may not function properly afterwards.
DETAIL -
6 user registry handles leaked from \Registry\User\S-1-5-21-3799963273-679199981-738785089-500:
Process 2348 (\Device\HarddiskVolume2\Windows\System32\cmd.exe) has opened key \REGISTRY\USER\S-1-5-21-3799963273-679199981-738785089-500
Process 6532 (\Device\HarddiskVolume2\Windows\System32\Robocopy.exe) has opened key \REGISTRY\USER\S-1-5-21-3799963273-679199981-738785089-500
Process 2348 (\Device\HarddiskVolume2\Windows\System32\cmd.exe) has opened key \REGISTRY\USER\S-1-5-21-3799963273-679199981-738785089-500\Software\Microsoft\Windows NT\CurrentVersion
Process 2348 (\Device\HarddiskVolume2\Windows\System32\cmd.exe) has opened key \REGISTRY\USER\S-1-5-21-3799963273-679199981-738785089-500\Control Panel\International
Process 6700 (\Device\HarddiskVolume2\Windows\System32\conhost.exe) has opened key \REGISTRY\USER\S-1-5-21-3799963273-679199981-738785089-500\Control Panel\International
Process 6532 (\Device\HarddiskVolume2\Windows\System32\Robocopy.exe) has opened key \REGISTRY\USER\S-1-5-21-3799963273-679199981-738785089-500\Control Panel\International

Handle leak when using ADO2.7 access oracle

Ado version:2.7
OS:Window2000 professional
Oracle Server:9.2.0.1.0
Client Provider:9.2.0.1.0
Using Oracle OLEDB connection oracle
when i execute such function in my test program continuously:
Handle count of the program will increase.I know handle will increase for connection pool ,but it will stop increasing when handle count reach one value. i think this is a problem that ADO cann't match with Oracle OLEDB
better.
Any suggestion?
Set mConOracle = New Connection
mConOracle.CursorLocation = adUseClient
mConOracle.ConnectionString = "Provider=OraOLEDB.Oracle.1;Password=123;Persist Security Info=True;User ID=abc;Data Source=aaa;OLE DB Services=-1; "
mConOracle.Open
mConOracle.Close
Set mConOracle=Nothing

Ok,
I tried out connection pooling switching on/off. Also waited some minutes for the pool timeout. But nothing happened.
So I made some further tests and this is what I found out:
- The left handles are all semaphores
- To generate a handle leak it is necessary to create an ADO object, call connect and do a database query. Actually some data must be transmitted over the network. Then close connection, release ADO object. -> 2-3 semaphore handles are left.
- Handle leak occurs indepentendly of apartment or multi threaded
- MDAC 2.7, MDAC 2.8 was used with no success
However, we hat one piece of software here, which didn't have handle leaks. So I did some more investigation on that phenomena.
This is what happened and could be used as a workaround until a fix is available:
- I recognized, that if at least one connection (which has been really established once by the underlying components) has been opened and is kept open, it is possible to create more ADO objects, use them for database retrieval and release them again without having the handle count increased.
- So the handle leak seems only to occur, if there is no more database connection in use and one of the underlying components tries to release everything. Each time this happens 2-3 semaphore handle are left.
- Finally my current workaround is to create and open on initalization of my process an ADO object and the database connection and leave this object alone without touching it again until the process ends. For every database query in any thread I can now use a new ADO object, without having the handles increased and never released.
So, this is the end for now. I hope this information can help somebody to figure out where the problem is eventually located and a fix could be released.
Hopefully,
Markus (writing under Uwes account)

Handle Leak -- HPZ12 process

Hello. I believe I am encountering an issue associated with an HP driver that is causing my PC to crash. I don't want to disable the services associated with the printer but it is causing my system to become unstable. I did some research and found out the svchost.exe process was generating up to and over 1 million handles. When I ran the tasklist utility below, it indicated that it was associated with pml driver HPZ12. The PID in question was PID # 2484. Can you help me?
I am running Windows XP SP3.
C:\Documents and Settings\Owner>tasklist /FI "Imagename eq Svchost.exe" /SVC
Image Name                   PID Services
========================= ====== =============================================
svchost.exe                 1376 DcomLaunch, TermService
svchost.exe                 1488 RpcSs
svchost.exe                 1636 AudioSrv, Browser, CryptSvc, Dhcp, dmserver,
                                 ERSvc, EventSystem,
                                 FastUserSwitchingCompatibility, helpsvc,
                                 HidServ, lanmanserver, lanmanworkstation,
                                 Netman, Nla, RasMan, Schedule, seclogon,
                                 SENS, SharedAccess, ShellHWDetection,
                                 srservice, TapiSrv, Themes, TrkWks, W32Time,
                                 winmgmt, wscsvc, wuauserv, WZCSVC
svchost.exe                 1768 Dnscache
svchost.exe                 1900 LmHosts
svchost.exe                 1056 WebClient
svchost.exe                  248 hpqcxs08, hpqddsvc
svchost.exe                  276 HPSLPSVC
svchost.exe                 2768 SSDPSRV
svchost.exe                 2832 stisvc
svchost.exe                 2484 Pml Driver HPZ12 (this one is the handle leak!!!)
svchost.exe                 4728 Net Driver HPZ12

Hello. I believe I am encountering an issue associated with an HP driver that is causing my PC to crash. I don't want to disable the services associated with the printer but it is causing my system to become unstable. I did some research and found out the svchost.exe process was generating up to and over 1 million handles. When I ran the tasklist utility below, it indicated that it was associated with pml driver HPZ12. The PID in question was PID # 2484. Can you help me?
I am running Windows XP SP3.
C:\Documents and Settings\Owner>tasklist /FI "Imagename eq Svchost.exe" /SVC
Image Name                   PID Services
========================= ====== =============================================
svchost.exe                 1376 DcomLaunch, TermService
svchost.exe                 1488 RpcSs
svchost.exe                 1636 AudioSrv, Browser, CryptSvc, Dhcp, dmserver,
                                 ERSvc, EventSystem,
                                 FastUserSwitchingCompatibility, helpsvc,
                                 HidServ, lanmanserver, lanmanworkstation,
                                 Netman, Nla, RasMan, Schedule, seclogon,
                                 SENS, SharedAccess, ShellHWDetection,
                                 srservice, TapiSrv, Themes, TrkWks, W32Time,
                                 winmgmt, wscsvc, wuauserv, WZCSVC
svchost.exe                 1768 Dnscache
svchost.exe                 1900 LmHosts
svchost.exe                 1056 WebClient
svchost.exe                  248 hpqcxs08, hpqddsvc
svchost.exe                  276 HPSLPSVC
svchost.exe                 2768 SSDPSRV
svchost.exe                 2832 stisvc
svchost.exe                 2484 Pml Driver HPZ12 (this one is the handle leak!!!)
svchost.exe                 4728 Net Driver HPZ12

Camera Eventually stops connecting possibly caused by a handle leak

Can somebody tell me how to write an app that display a picture of the webcam on screen, change the size of video shown and remove it from the screen without the camera eventually not displaying and the created handles being left behind.
From my investigation any camera with the usbvideo.sys driver is affected, which will be at least 50% of webcams out there.
Sometimes air locks up and becomes unresponsive / sometimes it just stops displaying the camera, it depends upon the camera.
Tested with lots of different cameras on Windows 7 and 8 with lots of versions of the Air/Flex Frameworks.
Heres a simple app to test it.
<?xml version="1.0" encoding="utf-8"?>
<s:WindowedApplication xmlns:fx="http://ns.adobe.com/mxml/2009"
    xmlns:s="library://ns.adobe.com/flex/spark"
    xmlns:mx="library://ns.adobe.com/flex/mx"
    creationComplete="windowedapplication1_creationCompleteHandler(event)">
<fx:Script>
<![CDATA[
import mx.collections.ArrayList;
import mx.events.FlexEvent;
import spark.events.IndexChangeEvent;
private var camera:Camera;
[Bindable]
private var cams:ArrayList;
private var video:Video;
[Bindable]
private var autoInProgress:Boolean;
[Bindable]
private var totalAttempts:int = 0;
private var currentAttempts:int = 0;
protected function windowedapplication1_creationCompleteHandler(event:FlexEvent):void
cams = new ArrayList(Camera.names);
protected function selectedCamera_changeHandler(event:IndexChangeEvent):void
camera = Camera.getCamera(selectedCamera.selectedIndex.toString());
if (camera)
camera.setMode(640, 480, 30);
private function start() : void {
currentAttempts = 0;
autoInProgress = true;
if (resizeTest.selected) {
addVideoAndAttachCamera();
resize();
else {
attachDetach();
private function addVideoAndAttachCamera() : void {
if (camera) {
video = new Video(camera.width, camera.height);
videoContainer.addChild(video);
video.attachCamera(camera);
private function detachCameraAndRemoveVideo() : void {
video.attachCamera(null);
video.clear();
videoContainer.removeChild(video);
video = null;
private function attachDetach() : void {
++ currentAttempts;
++ totalAttempts;
if (camera) {
addVideoAndAttachCamera();
memoryUsage.text = "System Memory Usage: " + (System.totalMemory).toString() + "bytes";
setTimeout(function():void {
detachCameraAndRemoveVideo();
if (currentAttempts < int(attempts.selectedItem)) {
attachDetach();
else {
autoInProgress = false;
}, int(delay.selectedItem));
private function resize() : void {
++ currentAttempts;
++ totalAttempts;
if (camera) {
camera.setMode(640, 480, 30);
memoryUsage.text = "System Memory Usage: " + (System.totalMemory).toString() + "bytes";
setTimeout(function():void {
if (currentAttempts < int(attempts.selectedItem)) {
resize();
else {
detachCameraAndRemoveVideo();
autoInProgress = false;
}, int(delay.selectedItem));
]]>
</fx:Script>
<s:VGroup>
<s:HGroup>
<s:Label enabled="{!autoInProgress}" text="Camera" />
<s:ComboBox enabled="{!autoInProgress}"
id="selectedCamera"
dataProvider="{cams}"
change="selectedCamera_changeHandler(event)"/>
<s:Label id="memoryUsage" />
<s:Label text="{totalAttempts}" />
</s:HGroup>
<s:HGroup>
<s:Label text="Auto Connect/Disconnect" enabled="{!autoInProgress}" />
<s:ComboBox id="attempts" enabled="{!autoInProgress}" selectedIndex="1">
<mx:ArrayCollection>
<fx:String>1</fx:String>
<fx:String>5</fx:String>
<fx:String>10</fx:String>
<fx:String>50</fx:String>
<fx:String>75</fx:String>
<fx:String>100</fx:String>
<fx:String>500</fx:String>
<fx:String>1000</fx:String>
<fx:String>5000</fx:String>
<fx:String>10000</fx:String>
</mx:ArrayCollection>
</s:ComboBox>
<s:Label text="times" enabled="{!autoInProgress}" />
<s:CheckBox id="resizeTest" label="Resize Test?" />
<s:Button enabled="{!autoInProgress}" click="start()" label="Start" />
</s:HGroup>
<s:HGroup>
<s:Label text="Delay" enabled="{!autoInProgress}" />
<s:ComboBox id="delay" enabled="{!autoInProgress}" selectedIndex="1">
<mx:ArrayCollection>
<fx:String>1000</fx:String>
<fx:String>1500</fx:String>
<fx:String>2000</fx:String>
<fx:String>3000</fx:String>
</mx:ArrayCollection>
</s:ComboBox>
</s:HGroup>
<mx:UIComponent id="videoContainer" width="640" height="480" />
</s:VGroup>
</s:WindowedApplication>
The resizeTest checkbox shows that you can make the camera lockup just by repetitively calling cam.setMode().
I have submitted a bug into the bugbase. Bug#3850401 - Handle leak with video.attachCamera leading to inoperable camera

Avrom,
I have never seeb this error before.
It certainly looks like an OC4J issue. Please try to get an answer on this in the OC4J forum.
Steven Davelaar,
JHeadstart Team.

Jvm unnamed windows events handle leak 1.3.1_08-b03 - 1.4.2-b28

Hello,
I have an server application that leaks windows unnamed event handles on small loads. (200 network connections) I've used the process explorer from www.sysinternals.com to find the type of handles that where leaking. I've run my application through jprobe several times and i'm not leaking any java objects. it doesn't happen on every run. It can run about 5 to 10 times with no leak but as i continue running a request that has 200 network connnections it will leak one handle. Over time they add up memory increases and eventually we get a out of memory error and the server has to be restarted
My application uses the following
java version "1.3.1_08"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_08-b03)
Java HotSpot(TM) Client VM (build 1.3.1_08-b03, mixed mode)
windows server 2000 service pack 3 (I've tried sp1 and sp2 same issue)
starting and stopping threads
inet jdbc driver una2000
zlib compression libraries
encryption DES
sockets
no jni code
My network code uses input.available() and Socket.setSoTimeout() I don't think the setSoTimeOut time is timing anything out on these small runs.
I've also have run it with
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)
I've tried not stopping any threads from my thread pool and it made no change. It still leaks! :-(
Does anyone know what creates the unamed event handles? Are they created by synchronization? Since my applications uses so many different api's it's like looking for a needle in a hay stack.
p.s. I've been working on this problem on and off for about 1 month. I've search the java forums and google.
Thanks
Alexander Anguiano

My message has been here for a while and is off the first page. :-( Oh, well. I thought I would update this just incase anyone was following it. (can I award my self those duke dollars?)
I think i've found the problem of why we are leaking handles. In the first 10 minutes it leaked 3 handles.(they may not have leaked but are resource that our application needed because of all the lazy initialization that we do) I've been runing a 200 task request every 5 minutes for the last 6 hours and have not leak any handles. The problem appears to be with calls to socket.setSoTimeout. I set it to 0. This effectively tells the socket to never time out. This is not an acceptable solution to the problem. I will be working on that next.
Has any one had problems with the socket.setSoTimeout?
If not then it may have to do with our simulated select. We have one thread that handles connection. Once the connection is established it's put on a list that get's polled [input.available()] that is handled by thread 2 if there is data then it gets handled by a worker thread [thread n-12]. Once the worker thread has read up to 4K of data it is put back on thread 2. I'm thinking that it has to do with so many thread doing a little work on it.

Token Handle Leak in RDPShell.exe on 2012 R2 (does not occur in 2008)

I have several Terminal Services farms running both 2008 and 2012 R2.
Only those farms running 2012 exhibit the problem of excessive token handles in RDPShell.exe
On 2008, the handle count is around 210 (a mix of Desktop, Directory, ETWRegistration, Event, File, Key, Mutant, Process, Section, Thread, WindowStation).
However, on 2012 R2 (running the same client application) RDPShell leaks Token handles (with handle counts in the thousands). The current maximum handle count for RDPShell on one RDS server is 7620 handles...
Example below taken from ProcessHacker:
Token, CORPORATE\[LoggedOnUserName]: 0xda8e99c, 0x7644
Token, CORPORATE\[LoggedOnUserName]: 0xda8e99c, 0x764c
Token, CORPORATE\[LoggedOnUserName]: 0xda8e99c, 0x7650
Token, CORPORATE\[LoggedOnUserName]: 0xda8e99c, 0x7654
Token, CORPORATE\[LoggedOnUserName]: 0xda8e99c, 0x7658
Token, CORPORATE\[LoggedOnUserName]: 0xda8e99c, 0x765c
Token, CORPORATE\[LoggedOnUserName]: 0xda8e99c, 0x7660
Token, CORPORATE\[LoggedOnUserName]: 0xda8e99c, 0x7664
Token, CORPORATE\[LoggedOnUserName]: 0xda8e99c, 0x7668
Token, CORPORATE\[LoggedOnUserName]: 0xda8e99c, 0x766c
I would like to raise this as a Connect bug, however cannot see how to raise bugs on Connect for any Windows Operating systems.
Is anyone else experiencing similar?

Hi Brett,
Thank you for posting in Windows Server Forum.
Can you let us know, with which application you are facing the leaking process?
There are certain scenario when you can face this error, which is occurring in server 2008 R2. You can check with
this article
for reference. According to that, it might occurs due to some allocated memory is not released correctly in the Rdpshell.exe process. Here you need to close all the running application and need to wait for some time and retry again to work back.
Hope it helps!
Thanks.
Dharmesh Solanki
TechNet Community Support

Call executable handle leak

We noticed in TestStand 4.1 that when we use "Call Executable" on a batch file:
with "no wait" it leaks a handle on each call
with other view options thatn "show minimized" it leaks GDI objects
We can work around the first issue by using CloseHandle (from kernel32.dll) on RunState.PreviousStep.ProcessHandle, but I would like to know whether these are known issues and are addressed in later versions of TS.
Best regards
Peter

In later versions of TestStand, the default behavior of a new callexecuteable step is to NOT store the process handle at all (instead it gets closed immediately). There is a setting for whether or not to store the handle and an expression to specify where to store it as shown below:
For the GDI object leak, are you seeing a leak in the TestStand process or is the GDI object leaking because the handle hasn't been closed yet, so the other process is still around and still using GDI objects? Does the GDI leak go away if you close the process handle? If you call callexecutable in a tight loop does the number of GDI objects grow unbounded or does it level off (i.e. is it really a leak or a one-time allocation)?
-Doug

Handle leak

Why does each iteration of this code leak 4 handles? Is there some other statement that must be issued to cleanup the Oracle connection completely?
The program was run from Jdeveloper 9.0.3.10.35 using Oracle Client 9.2.0.1.0.
package mypackage3;
import sqlj.runtime.*;
import sqlj.runtime.ref.*;
import java.sql.*;
import oracle.sqlj.runtime.*;
import sqlj.runtime.ref.DefaultContext;
public class connTest
public connTest()
public static void main(String[] args) throws InterruptedException
Date currentDateTime;
while (true) {
try {
Oracle.connect("jdbc:oracle:oci8:@dbname", "user", "passwd", false);
#sql {select sysdate into :currentDateTime from dual};
catch (SQLException se) {
System.out.println(se);
try {
Oracle.close(DefaultContext.CLOSE_CONNECTION);
Oracle.connect("jdbc:oracle:oci8:@dbname", "user", "passwd", false);
catch (SQLException se) {
System.out.println(se);
Thread.sleep(5000);
}

I'm checking the handle count for the jvm running the program in Task Manager.
I expect the Oracle.close to clean up so that all resources used by the connection being closed are made available for garbage collection. Also there's no memory leaking I can see - just the handles. I've also tried a code variation that allocates a new defaultContext then after the close sets it to null. That doesn't seem to make any difference. I'll try running that in a 1.4 jvm and see if I can force garbage collection. I suspect that the handle's allocated on the connect aren't being closed in windows land on the Oracle.close. I wouldn't expect the garbage collecter to actually know that the contents of memory are a window's handle and that when that memory is garbage collected a windows call must be made to close the handle.

File Handler Leak?

After we upgrade to 4.0.71 from 3.0, we see multiple file handlers are opened for the last jdb file. We have 100+ clients and each clients have their own environment, thus caused us top the file handler limit on linux.
We are using
OS: Linux 2.6.18-92.1.6.el5 #1 SMP Fri Jun 20 02:36:06 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
The environment is writable.
I would like to confirm if this is related to the issue fixed in 4.0.92:
Fix a problem where cleaned and deleted log files could accumulate in the log cleaner's backlog, or list of files to be cleaned. This occurs when multiple cleaner threads are configured. The impacts of this problem are:
1. The EnvironmentStats.getCleanerBacklog stat is incorrect, which could lead the application to unnecessarily increase the number of cleaner threads.
2.
3. If EnvironmentConfig.CLEANER_MAX_BATCH_FILES is set to a non-zero value, log cleaning is disabled when the number of deleted files in the backlog reaches this limit.
[#18179]
or is another bug or expected behavior.
To be specific:
I ran the lsof for the berkeley DB directory:
java 13665 mybuys 147r REG 253,0 141869 25927939 /berkeley-db/00000000.jdb
java 13665 mybuys 148r REG 253,0 141869 25927939 /berkeley-db/00000000.jdb
java 13665 mybuys 279rw REG 253,0 0 25927936 /berkeley-db/je.info.0.lck
java 13665 mybuys 280w REG 253,0 0 25927937 /berkeley-db/je.info.0
java 13665 mybuys 281uw REG 253,0 0 25927938 /berkeley-db/je.lck
java 13665 mybuys 282r REG 253,0 141869 25927939 /berkeley-db//00000000.jdb
and note that there are 3 instances of 00000000.jdb. I only see one file hander to this file when server just restart. We have a periodical process to refresh the Berkeley DB from data feed, and we see two handler increased in each refresh. The environment handler, entityStore, and primaryIndex are all singleton per client.
Can someone explain why there is a need to have multiple hanlders opened for one jdb file (and seems always the last one). Is there a workaround with it.
Edited by: JoshWo on Mar 2, 2010 3:14 PM

Everything you asked about is per environment, not per environment handle. In general, we never allocate expensive resources like file handles for each environment handle.
For us, it is not critical to have many file handlers but we just need to be able to estimate before deployment so OS limit can be set correctly (I believe the max is 40K per process on Linux). Any formula to publish?For any environment:
<li> Read-only handles: You can set the maximum to 3, but that is the smallest maximum you can specify. If you only have one log file then only one handle will be open. But if you have 3 log files, then 3 file handles may be opened.
<li> je.lck: 1 handle is always open.
For a read-write environment, there are the following 3 additional handles (added to the above):
<li> Write handle: 1 handle for writing.
<li> Fsync handle: 1 handle for fsync.
<li> je.lck: 1 additional handle for exclusive locking.
Also, you mentioned "maximum number of open-for-read handles is reached". Can you point a documentation link on this parameter or elaborate more here? Is it per environment handler or per environment?EnvironmentConfig.LOG_FILE_CACHE_SIZE is in the javadoc, in the je package.
So overall (if you set LOG_FILE_CACHE_SIZE to 3), you should assume:
-- 4 handles for a read-only environment
-- 7 handles for a read-write environment
I suggest you test this. I'm giving you these numbers by reading the code, not by testing.
--mark

Creative Cloud Leaks Thread Handles

I have Creative Cloud version 1.8.0.447 running on windows 7, and I notice that it leaks a Thread Handle, about 4 times, or so, per minute. Since I leave my computer on most of the time, after a few days, the number of leaked Thread Handles is up in the tens of thousands.
I can see the thread handles leaking using Process Explorer.
Generally when a thread ends, its handle needs to be closed, or else the handle will stay active forever, or until the process ends. It looks like the programming team is not closing these handles after the threads end.
Please, adobe, fix this problem in a future release of creative cloud.
-Todd

Some 10.9.x links
-next link says After Effects, but check YOUR permissions !!!
-http://blogs.adobe.com/aftereffects/2014/06/permissions-mac-os-start-adobe-applications.ht ml
-Mac 10.9.4 and OpenCL issue https://forums.adobe.com/thread/1514717
-Mac 10.9.3 workaround https://forums.adobe.com/thread/1489922
-more Mac 10.9.3 https://forums.adobe.com/thread/1491469
-and https://forums.adobe.com/thread/1507936
or
A chat session where an agent may remotely look inside your computer may help
Creative Cloud chat support (all Creative Cloud customer service issues)
http://helpx.adobe.com/x-productkb/global/service-ccm.html

IE6 leaks "Handles" when calling *ANY* Java applet

Hello all IE experts,
It seems that IE has "Handles" leak when it calls Java Applet.
Every call to a Java method from JavaScript, IE allocate a handle and does
not free it.
THIS DOES NOT HAPPEN when I use mozilla or Netscape.
Versions:
* Windows 2000 SP 3 (The most recent, with all fixes of hfnetchk)
* Internet Explorer (The most recent one, with all fixes of hfnetchk)
Version 6.0.2800.1106
SP1
Q328970
Q324929
Q810847
Q813951
* Java Plug-in - 1.4.1_02-b06
If you compile the applet and use the test html, then press "Test" you will
notice that 1000 (or more) handles are allocated (At Windows Task Manager).
If you press again you will see that another 1000 (or more) handles are
allocated. The handles are NEVER released, even if you browse to other
sites. You can enjoy this process until there are no more handles to
allocate... :)
Notice that the applet I use does nothing... I've checked this with various
of applets on the web and the results are the same.
Can anyone help?
Best Regards,
Alon Bar-Lev
** The following html is used: (test1.htm)
<html>
<head>
<script LANGUAGE="JavaScript">
function OnTest () {
for (var i=0;i<1000;i++) { a1.method1 (); }
</script>
</head>
<body>
<input type=button onclick="OnTest ()" value="Test"></input>
<APPLET code="test1.applet1.class" archive="test1.jar" id="a1" name="a1">No
Java</APPLET>
</body>
</html>
** The following applet: (test1/applet1.java)
package test1;
import java.applet.*;
public class applet1 extends Applet {
public void method1 () {}
** The following makefile: (Makefile)
JAVAC="$(J2SE)\bin\javac" -classpath $(CLASSPATH)
JAR="$(J2SE)\bin\jar" -cvf
CLASSPATH=.
all:
$(JAVAC) test1/*.java
$(JAR) test1.jar test1/*.class

New information:
This happens from Java version 1.4.0_01.
This did not happen in Java version 1.4.0.
Alon.

Handling a panic when using DB_REGISTER

I have just run into a problem which I think is a bug in BerkeleyDB 4.4.20. I am checking to see if there is any known work-around or patch for this.
We have a design in which two processes use one environment. Both processes employ the combination of DB_REGISTRY and DB_RUN_RECOVERY when they open the environment. The process also have a panic handler in them so that if the panic exception is thrown while they run, they close and reopen the environment with the same flags.
The use of the flags in this way achieves the benefit of the DB_REGISTER mechanism. The panic handler addresses the fact that if one process restarts after a failure and thus starts recovery, it's peer can handle the panic which ensues and will close/reopen its environment, thereby reattaching to the recovered environment. Based on the exclusive lock in the registry mechanism, there are no race conditions on recovery - the processes both end up reconnected to the recovered environment - and all of this seems to be working just fine.
However, if the two running processes experience a panic in the environment because of some other bug, I see a problem. We are concerned here for panics which could arise due to shared memory corruption, an internal BerkeleyDB bug, etc. (Anything else that might cause the panic bit to get set.) We simulated this in testing by adding a JMX control which allows us set the panic flag as the processes run. We want to make sure that in those cases, the application will at least attempt to close and recover the environment and will still be able to carry on if recovery is possible.
When the panic bit is set in this way, the panic handler is invoked, the processes both try to close the environment and reopen it. The Environment.close() call is failing in this case with a RunRecovery exception just as it does as with a process crash scenario. I think this is fine. However, when the processes try to reopen the environment, they are getting an invalid argument exception because the Registry mechanism believes that the processes both have the environment open already. The problem is that environment.close() doesn't unregister the processes when the environment is paniced.
This problem doesn't occur when a process restarts because it gets a new PID, which allows it to proceed with the open, and then the existing registry is removed as part of the recovery, which in turn allows its peer to reconnect as well without any problem.
Looking a bit deeper, it also seems that once the environment is paniced, Environment.close() doesn't clean up any resources - it doesn't unmap the regions, close file descriptors, etc, leaving the resources used by the closed Environment handle "leaked".
I think this is a bug. In 4.6.21, I noticed (from the code) that __env_close_pp() now closes file handles even when the panic bit is set, and it seems to me that there is a general need here for the Environment.close() to always properly free up resources even when the environment is paniced, so that an application noticing the panic can attempt to reopen it. i.e. __env_close should close relevant file descriptors and unmap associated files/regions from the processes address space so that they can be reclaimed by the system, even when the environment is paniced.
This behavior of Environment.close() also seems like it can cause an infinite resource leak. i.e. If process A is running along, and process B is having problems and crashes/gets restarted several times, then with each such restart of B, process A ends up with more anonymous mapped memory regions and open file descriptors attached to it which are no longer being used. (i.e. with each restart of B, which will perform recovery, A sees a panic and does a close/reopen, which allows it to attach to the new recovered region successfully, but never closes the file descriptors or attached regions of the old paniced environmet.) Only when A shuts down would it completely detach. I think this is the issue 4.6.21 was attempting to address. I may have no choice but to try to hand-code a patch for 4.4.20 which does the same.
Does any patch for this issue already exist for 4.4.20 ?? Does the code in 4.6.21 address this resource-leak issue in full?

Hi Samira,
Please close the duplicate thread.
Regards,
Eric

Do I need to worry about these event handlers in a grid from a memory leak perspective?

I'm pretty new to Flex and coudn't figure out how to add event handlers to inline item renderer components from the containing file script so I attached the listnerers simply as part of the components themselves (eg <mx:Checkbox ... chnage="outerDocument.doSomething(event)"../>):
<mx:DataGrid id="targetsGrid" width="100%" height="100%" doubleClickEnabled="true" styleName="itemCell"
      headerStyleName="headerRow" dataProvider="{targets}"
      rowHeight="19" fontSize="11" paddingBottom="0" paddingTop="1">
     <mx:columns>
     <mx:DataGridColumn width="78" dataField="@isSelected" headerText="">
     <mx:itemRenderer>
          <mx:Component>
               <mx:HBox width="100%" height="100%" horizontalAlign="center">
                    <mx:CheckBox id="targetCheckBox" selected="{data.@isSelected == 'true'}"
                         change="outerDocument.checkChangeHandler(event);"/>
                    <mx:Image horizontalAlign="center" toolTip="Delete" source="@Embed('/assets/icons/delete.png')" useHandCursor="true" buttonMode="true"
                         click="outerDocument.deleteHandler(event);"/>
                    <mx:Image id="editButton" horizontalAlign="center" toolTip="Edit" source="@Embed('/assets/icons/edit-icon.png')" useHandCursor="true" buttonMode="true"
                         click="outerDocument.editHandler(event);"/>
               </mx:HBox>
          </mx:Component>
     </mx:itemRenderer>
     </mx:DataGridColumn>
          <mx:DataGridColumn id="Name" dataField="@collectionDesc" headerText="Name" itemRenderer="com.foobar.integrated.media.ui.component.CellStyleForTargetName"/>
          <mx:DataGridColumn id="Created" width="140" dataField="@createDateTime" headerText="Created" labelFunction="UiHelper.gridDateFormat" />
     </mx:columns>
</mx:DataGrid>
This grid is part of a view that will get destroyed and recreated potentially many times during a user's session within the application (there's a large dynamic nature to the app and views are created at run-time.) By destroyed I mean that the view that holds the above datagrid will no longer be referenced under certain circumstances and an entire new view object is created (meaning the old datagrid is no longer refernced and a new one is created.)
I heard you should clean up event handlers when they are no longer used, and I know at what point the view is destroyed, but I don't know how to clean up the event handlers added to the item renderer components? Is it something that the Flex garbage collector will handle efficiently?
Also, on a somewhat related note, how could I push the item renderer to an external component since in my event handlers for the item renderer buttons I need a reference to the datagrid.selectedIndex which, as an external item renderer I wouldn't have access to this containing grid?

No. You don't need explicit cleanup in this case: if your outerDocument is going away, you have nothing to worry about. The event handler leak can happen in sort of the reverse situation: suppose you have a long-lived MyView that contains a custom DataGrid like the one below. Now suppose that MyView frequently destroys and re-creates the grid. And suppose that on its creationComplete event, the grid registers a listener for outerDocument's (MyView's) enterFrame Event. Unless you explicitly remove this listener, MyView will still have a reference to it even after the grid that registered the listener is destroyed (and garbage collected).
This is a pretty contrived example, but it sort of illustrates the potential for leaks: a certain component is elligible for garbage collection, but some longer-lived component holds a reference to it (or part of it, such as a listener function). If the longer-lived component is elligible for GC as well, you don't really need to worry about proper cleanup. That's what you're paying the GC processor cycles for.

Handle leaks?

Similar Messages

Maybe you are looking for