In search of ... a Gateway cure ...

[barney]

OK, I really don't know how else to entitle this.

The Dell i7 laptop is effectively dead.  I have a Gateway 15.6" laptop with an Intel i3 which has been a functional backup system.  However, I've been spoiled to the 17.3" screens.  Heavy, but the visual real estate has become crucial to mine eyes  .

So, I let myself be seduced by the price of a Gateway 17.3" laptop.  It has an AMD 4-core processor, the first non-Intel box I've ever had, I think.

Problem is, I cannot run it for more than eight ( hours, often less.  The system quits working.  It tells me it's out of system resources.  Or it tell me there's no thread available (?!?).  I have to power off with the hardware switch.  What's more, now the 15.6" box has the same problem!  The contagion made me think of course, of malware, but every tool I have says that's not an issue.  Problematic, at best, but I'm reasonably reassured  this is not a malware problem.

OK, that's the background.  What I want to find is some analytic(s) that will tell me where there is a resource shortage.  Typically, CPU will be less than 35-40% usage, memory normally 60% or less usage.  Task Manager, Process Manager, et. al., don't tell me anything worthwhile.  So, is there anything other than serendipity that can tell me what's going on?  (Oh, pardon the typos - I dislocated & separated my right shoulder a week agone, so my typing skills are somewhat ailing  .)

If it matters, there's very little similarity in software loads on the two (2) boxes.  some sidebar apps and a few note apps are all they have in common, save for the Gateway software.  Both running Win7 Ultimate.  The Intel CPU is i3 M 330 2.16GHz, the AMD is A6-3420M.  Both have 4G RAM.  The Intel box has an Intel video driver, and the AMD box has a Radeon  HD 6520G.

[app103]

If both systems are having the same issue, I'd start by looking at the list of software that they have in common, even if that list is short.

[barney]

Already did.  Nothing stands out.  With two (2) different processors & two (2) different video configs, even the Gateway software is pretty much disparate.  That's part of what bumfuzzles me.  These boxes have very little in common - name don't count  - but when I added the 2nd box to the network, both [apparently] came down with the same condition.  No way that should happen.  I'm inclined to think drivers, but I don't have anything that'll let me examine that theory in fine:  all my tools are pretty coarse for something like this.

But when the system(s) basically say resource shortage or no thread, there is some measure I'm not taking, not able to take, or don't know to take, to determine that resource.  Without that determination, I'm hard put to redress the issue - I don't even know the issue  .

[4wd]

- but when I added the 2nd box to the network, both [apparently] came down with the same condition.  No way that should happen.

Just to clarify, are you saying that:
a) the Intel Gateway was already doing it and then when you added the AMD Gateway to the network it started doing it, or
b) they were both running fine until they were both added to the network, or
c) the AMD Gateway started doing it when connected to the network and then the problem migrated to the Intel Gateway when it was connected.

Would it be a good idea to try them both when they aren't connected to any network, have them standalone and running a burn-in program, (eg. Super-Pi), for 12 hours or so.

That should isolate it to network related or not, then you can start by putting network settings back to basic levels, (eg. no Homegroup, etc.).

[mouser]

If it's really reproducible then I suggest what app suggests, that it sounds like a software issue.
I would post the exact error the next time it occurs, and post us the ctrl+alt+del process list sorted by highest Mem Usage.
There are other more detailed tools for showing use of system resources, but that would be a good start.

[rgdot]

I know this is very ridiculous to post but the couple of times I have seen resource issues has been because the hard disk is getting to 85%+ full and Windows hates that

[barney]

Sorry, forgot to check the notify box.

@rgdot:

Yeah, I've had that happen, but not the case in this particular instance.

@mouser, et. al.,

There's a difference between reproducible and recurring.  When this happens, I cannot run anything new, and most often cannot bring to the fore anything idling.  Have a couple of gadgets running, one of which shows CPU and RAM usage, another which shows  top n processes (in my case, ten (10)).  There's no consistent pattern there.  I have checked the Process Monitor gadget against both Task Manager and Sysinternals, all of which stay in agreement.  

But I cannot start another process/program when this arises.  And when I try to shut down/reboot through another gadget, the error message is:
"C:\Windows\system32\shutdown.exe
Insufficient system resources exist to complete the requested service."  If I try to restart/shutdown via the standard menu, nothing happens - no messages, no results, just a system on idle.

Once in a while I get a repeating series of error messages on the Intel (15.6" screen) with the window title of "Fail" (typical developer arrogance!) with the message body of:
cpu: -1
core: 0
thread: 0

Packages: 1
Cores per package: 2
Threads per package: 2.

Haven't seen the "insufficient thread" message come up lately so as to quote it, but it has shown on both machines from time to time.

Once this happens on either machine, it contaminates (?) the other.  The  only resolution is a BRS restart (well-l-l, the Intel box has a chrome switch and the AMD box a black one  ).

Side note:  one of the systems I worked on early in my "career" had a red start switch and a green stop switch:  those hardware designers may have been smarter than any of us knew at the time  .

[Edit]
Normally CPU is ~20% usage, and RAM less than 60% usage.  There are variations, but those numbers seem to be pretty much the top for each area.

[techidave]

This suggestion might be a bit off the wall but here goes.  Have you tried running a memory tester?  Although it seems unlikely that a new machine would have a bad stick, but anything is possible.

[barney]

One (1) of the first things I do on any new box.  Couple of corporate instances of memory infant mortality trained me into that  .

[x16wda]

Could be a pool shortage.  I just started looking at some similar instances myself (although with older servers).

One thing I have set up is a Microsoft tool, Memsnap.exe (in the Server 2003 resource kit).  I set up a scheduled task to run a batch file every 15 minutes with "memsnap -m c:\memsnap.log".  Then after it has a few snapshots saved you can look at the results with "memsnap -a c:\memsnap.log".  May not help, but if there's a memory leak it might point to the culprit.  (It's the simplest way I could find to watch for something like this, and it's free.)

[barney]

Now, that is a right knightly concept.  Thanks  !  Not something I'd run across before, but there's definitely a use for it, 'specially here and now.

[barney]

OK, it took seemingly forever, but I got it.  couldn't find it under 2003 server, but did find it as WinXP SP2 Support.  Then couldn't install it, as I don't currently have an XP box functional.  However, 7-Zip, to the rescue, and I was able to extract all the files.  Hopefully, it won't need an install, as such.  Most of the CLI stuff I've used in the past hasn't.  Equally hopefully, I'll find time this evening to set up a task schedule for it on each box.  Here's hoping.  (Hope I didn't put too much hope in here  .)

[x16wda]

Actually my task when I came into work this morning was to find a way to track pool growth, since my boxes were cooperative enough to spit out a semi-incriminating event before they locked up.  My remembrance of perfmon was that it was too convoluted to get set up, so I was about to write a quick script when I came across this.

I should point out that the -m parameter tracks by process, you could also use a -p parameter to track by tag but that's more work to track down if you get a hit 

Anyway, if you have a leaky app running on your boxes, hopefully this will show it up.  But if it's something innocuous that suddenly goes wild, you might not catch it.

PS- You can also just run a few snapshots by hand too, it doesn't need to be on a schedule...

[barney]

Since I'm never aware when one (1) of these suckers is liable to crater, I like the idea of a scheduled task.  A lot more data through which to plow, but I'm kinda hopin' the last two (2) or three (3) will tell a story.  I'd love to find a leak, but it'd be almost as useful if I don't, eliminating one (1) area of conjecture.  Oft times, a process of elimination is putatively more valuable than a hard discovery.  The side issues can become quite illuminating  .

[Shades]

It appears to me you should have a look at the 'Desktop Heap' of your system. Check on the Microsoft site if they have a version of 'Desktop Heap Monitor' for your OS. Its a small, free app that gives you a lot more insight in how the Windows Operating System actually uses RAM and how you can run out of resources while it appears there is more than enough left.

Having run this application on XP myself (and reading the MS documentation) I can tell you that you can (rather) easily pinpoint the culprit(s). 

[barney]

Desktop Heap Monitor doesn't seem to like Win7  , although usually Win7 will run almost anything that 2003 will run. 

Ever get that feeling that the universe just doesn't like ya?  I'm kinda there just now  .

[Shades]

Hmmm, you could try and use the instructions from this link to get things running on Windows OS's higher than XP.

You could try to set things manually in the registry. Make a backup of the registry before starting any of this. If you don't know, ask someone who does to help you out with this. Seriously!

Ok, after that obligatory registry-editing warning, lets go to key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows

There should be a line with the following or very similar text:
ObjectDirectory=\Windows SharedSection=1024,20480,768 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sxssrv,4 ProfileControl=Off MaxRequestThreads=16

The part 'SharedSection=1024,20480,768' is the most important section in your case. Adjusting these values can have serious implications for the well-being of your system, so tread carefully!

First some explanation
After the Microsoft® Windows® operating system has started, various areas of memory for resource tracking are reserved. Memory allocation of the heap is controlled by the number of open applications, windows, services and other resources. When a large number of processes are running, this heap may run out of memory.

How this memory is allocated has implications in your system. Changes in the default environment will affect overall performance considering your system architecture. The numeric values following SharedSection= control how desktop heap is allocated and are specified in kilobytes. Windows uses desktops classified as interactive and non-interactive.

The first SharedSection value (1024) is the shared heap size common to all desktops and changing this value is not (likely) necessary as this part of the heap contains the handles to windows, menus, icons, cursors, etc. and shared system settings. The second SharedSection value (20480) is associated with the "interactive" window station WinSta0. User objects like hooks, menus, strings, and windows consume memory in this desktop heap. Changing this value is not (likely) necessary as well.

The third SharedSection value (768) is associated with the "non-interactive" window station. If this value is not present, the size of the desktop heap for non-interactive window stations will be same as the size specified for interactive window stations (the second SharedSection value) and is used to keep track of processes without graphical user interfaces. Changes are likely necessary here.

Prior to Windows NT v3.5, Microsoft recommended a heap size of 3000 Kbytes (allowing for 460 processes). For later versions of NT and for Windows 2000 they recommend a size of only 512 Kbytes (allowing for 79 processes). Increasing the heap size beyond 512 Kbytes can cause instability or "blue-screening" of the system but the factors involved are sometimes obscure. Possibly, increasing the heap size depletes some other vital resource.

The size of the heap is the limiting factor controlling how many software packages can be active on any given system. Setting these values comes with a trade-off, your system will be able to support more running processes but overall performance will decrease. If performance is degraded too much for your liking, returning the third number to the original value should fix that.

The info above is gathered from several internet sources. However I tried the mentioned suggestions myself to initiate 80 Excel 2010 instances (on a WinXP SPIII with 2GByte of RAM) and that did work. You should never want to try that though, as your system will become really slow. An hour delay between mouse-click and computer responding to the mouse-click was not uncommon, when all instances were activated. Without that load, but with the changes to the heap that XP PC felt only a little bit slower than usual.

Please, don't take these Desktop Heap changes lightheartedly. During that time I did cross the limit (>80 Excel instances) and the BSOD monster did rear its ugly head almost immediately.

Sorry for the long post, I hope it can help you out though.