Failure to create handles

  • Thread starter Thread starter rudrf
  • Start date Start date
R

rudrf

I have been having this problem on two Vista machines (one Business, one Home
Premium, both x86), both less than a year old. The problem has been
happening several times a week. Since neither vendor is providing
SP1-compliant drivers, upgrading to SP1 is unfortunately not an option at
this point.

Essentially, after the physical memory goes beyond a certain point (about
3/4ths the total available memory), the system will fail to create window
handles. For instance, a dialog box might appear as an empty box, or might
not fully render. (A save changes dialog, for instance, might show the text
but not the buttons.) Attempting to begin applications generally yields out
of memory errors.

At this point, the system is generally unusable. By closing programs,
however, the problem abates. This suggested to me a memory problem, but both
systems have sufficient RAM (one has 2GB, the other 4GB) that is not
exhausted. I also ran the comprehensive memory diagnostics provided by Vista
and the vendor, and neither reported an error.

Has anyone else encountered this issue?
 
rudrf said:
I have been having this problem on two Vista machines (one Business, one
Home
Premium, both x86), both less than a year old. The problem has been
happening several times a week. Since neither vendor is providing
SP1-compliant drivers, upgrading to SP1 is unfortunately not an option at
this point.

Essentially, after the physical memory goes beyond a certain point (about
3/4ths the total available memory), the system will fail to create window
handles. For instance, a dialog box might appear as an empty box, or
might
not fully render. (A save changes dialog, for instance, might show the
text
but not the buttons.) Attempting to begin applications generally yields
out
of memory errors.

At this point, the system is generally unusable. By closing programs,
however, the problem abates. This suggested to me a memory problem, but
both
systems have sufficient RAM (one has 2GB, the other 4GB) that is not
exhausted. I also ran the comprehensive memory diagnostics provided by
Vista
and the vendor, and neither reported an error.

Has anyone else encountered this issue?


I have not encountered this issue ...
but it sounds like one of the programs you are running in the mix of open
applications has a "memory leak".

A simple first step to identify the offending program might be to open Task
Manager and check the "Processes" tab occasionally -- as you go about your
normal computer routine. Watch for processes that begin to use up a lot of
memory (you can sort the various columns by clicking their top bar). You
can also add or remove columns from the pull-down "View"/(Select Columns)
menu-bar item .

Good luck researching this mystery.

net_L
 
Thanks, net_blue.

I think a memory leak is likely part of the problem, plus the fact that I do
use memory-intensive applications. But these problems occur when (per PM)
the total memory consumed is significantly less than the physical memory
available.

Since virtual memory is enabled, I cannot understand why, even given a
memory leak, applications are being refused requests for memory. (Windows
provides no indication, through the UI or event log, that anything is amiss.)

When a managed application encounters a problem, the stack trace is
sometimes provided in the UI. Below is a sample (here from mmc). From the
callback downwards, the stack trace is consistent.

Microsoft.ManagementConsole.Internal.SnapInMessagePumpProxy.OnThreadException(Object sender, ThreadExceptionEventArgs e)
at
System.Windows.Forms.Application.ThreadContext.OnThreadException(Exception t)
at System.Windows.Forms.Control.WndProcException(Exception e)
at
System.Windows.Forms.Control.ControlNativeWindow.OnThreadException(Exception
e)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg,
IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.UnsafeNativeMethods.IntCreateWindowEx(Int32
dwExStyle, String lpszClassName, String lpszWindowName, Int32 style, Int32 x,
Int32 y, Int32 width, Int32 height, HandleRef hWndParent, HandleRef hMenu,
HandleRef hInst, Object pvParam)
at System.Windows.Forms.UnsafeNativeMethods.CreateWindowEx(Int32
dwExStyle, String lpszClassName, String lpszWindowName, Int32 style, Int32 x,
Int32 y, Int32 width, Int32 height, HandleRef hWndParent, HandleRef hMenu,
HandleRef hInst, Object pvParam)
at System.Windows.Forms.NativeWindow.CreateHandle(CreateParams cp)
at System.Windows.Forms.Control.CreateHandle()
at System.Windows.Forms.TabControl.CreateHandle()
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl()
at System.Windows.Forms.Control.ControlCollection.Add(Control value)
at Microsoft.ManagementConsole.FormView.InternalInitialize()
at
Microsoft.ManagementConsole.View.HandleInitializationRequest(IRequestStatus
requestStatus)
at Microsoft.ManagementConsole.View.ProcessRequest(Request request)
at Microsoft.ManagementConsole.ViewMessageClient.ProcessRequest(Request
request)
at
Microsoft.ManagementConsole.Internal.IMessageClient.ProcessRequest(Request
request)
at
Microsoft.ManagementConsole.Executive.RequestStatus.BeginRequest(IMessageClient messageClient, RequestInfo requestInfo)
at
Microsoft.ManagementConsole.Executive.SnapInRequestOperation.ProcessRequest()
at
Microsoft.ManagementConsole.Executive.Operation.OnThreadTransfer(SimpleOperationCallback callback)
 
rudrf said:
Thanks, net_blue.

I think a memory leak is likely part of the problem, plus the fact that I
do
use memory-intensive applications. But these problems occur when (per PM)
the total memory consumed is significantly less than the physical memory
available.

Since virtual memory is enabled, I cannot understand why, even given a
memory leak, applications are being refused requests for memory. (Windows
provides no indication, through the UI or event log, that anything is
amiss.)

{ snip }

This problem is beyond my expertise.

However, two things come to mind. In Task Manager, do you have Handles
column showing in Processes tab? This would be the thing to watch ( not
program memory).

Have you checked forums or tech support on those "memory-intensive"
applications. Maybe some clues might be found there.

- net
 
Thanks again for all your help, net. I looked at handles and it is remaining
constant at about 40k when I reproduce the problem.

At this point, I just don't have the technical expertise to see what's going
on. My plan at this point is to try to get upgraded drivers from the vendor
and install SP1; if that fails to correct the problem, I'll just downgrade to
XP for the time being.
 
rudrf said:
Thanks again for all your help, net. I looked at handles and it is
remaining
constant at about 40k when I reproduce the problem.

At this point, I just don't have the technical expertise to see what's
going
on. My plan at this point is to try to get upgraded drivers from the
vendor
and install SP1; if that fails to correct the problem, I'll just downgrade
to
XP for the time being.


Yikes. 30-Kb handles is on the verge of going nuclear. 40-Kb is the
culprit!

Your plan above makes sense. Good luck.

- NetLink
 
NetLink_Blue said:
Yikes. 30-Kb handles is on the verge of going nuclear. 40-Kb is the
culprit!

Your plan above makes sense. Good luck.

- NetLink


Oops. Just pure numbers ( in thousands) ... not Kb's. Ugh.
- N
 
Thanks.

In case anyone is encountering similar issues and comes across this thread,
installing SP1 seemed to fix the problem.
 
Back
Top