Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What does the ntvdm error message "The Win 16 Subsystem has insufficent resources to continue running. Click on OK, close your applications, and restart your machine." mean, and how can it be prevented?

(Interestingly, but presumably unrelated to the problem, the dialog box displaying the message is actually owned by the session's csrss.exe process.)

share|improve this question
    
Under what context are you getting this message? Please be specific. – user3463 Jan 11 '11 at 20:41
    
What I can make up: Win16 subsystem = the DOS emulation layer within WinXP The message means it somehow ran out of ressources (most probably memory), or maybe some component it depends on ran out of memory How to prevent it: Hard to say without details on applications used, etc – Marcus Jan 11 '11 at 21:00
    
@Randolph: Running a 16-bit windows app (which I thought was clear from the "Win 16 Subsystem" bit). In particular, it was happening with a freecell.exe copied from Windows 98 (along with the needed 16-bit version of cards.dll), but presumably most any 16-bit windows app would have sufficed. – SamB Jan 12 '11 at 0:08
    
It's not sufficient information to replicate the error on my side. Are you running Windows Vista? Windows 7? Server 2003 R2? WINE? My point is, is the problem the same for any 16-bit app you're running? What happens with compatibility mode? I can't make myself any more clear. – user3463 Jan 12 '11 at 4:11

According to http://www.vttoth.com/wow32.htm, this error messages occurs when GDI returns a handle higher than 16383 for a call made on behalf of a 16-bit Windows program. The handles could go up to 65535, but evidently they get right-left-shifted by 2 bits before being returned to the 16-bit app for some reason (presumably compatibility with something).

Before Windows XP, this couldn't happen, as only 16384 GDI objects were allowed to exist in any given session, but with XP the limit was increased to 65536 GDI objects. Since GDI evidently only allocates a new handle number when all lower handle numbers are in use, this can only actually occur if over 16384 GDI objects ever exist at the same time in the session.

Rebooting would generally remedy this situation, assuming that automatically-started programs don't eat through the first 16384 handles right off the bat.

If "fast user switching" is enabled, another option would be to log out, log some other account (e.g. "guest") in, and log in again. (The important thing here is to end up with a fresh "session"; if you weren't running in "session 0" to start with, the "log some other account" step is irrelevant.)

The linked page also offers a patch to remove the shifts from wow32.dll. Be warned, though: as the page says, applying this patch might be illegal; furthermore, it might be dangerous, and would certainly break whatever app(s) the shift was added for in the first place.

share|improve this answer
    
Just logging out and logging back in would fix this, since that ends the session. Rebooting not required. btw, under Vista and later the interactive users are NEVER running in session 0. Fast user switching would work too, and no need to actually log out from the first session - the second login gets a new session. – Jamie Hanrahan Jan 28 at 2:33

Ever since computers went from being 16bit computers to 32bit computers people have started seeing this error message. As stated by SamB - there are some ways in which you can coach the program in to running but ultimately - you will see this message again and again. The real problem is, as SamB talks about, that there are now so many other programs that run in the background that the 16K limitation is exceeded just by bringing up your computer. Under a 32bit OS this problem doesn't appear because you have so many more handles that can be worked with. BUT! Your 16bit application can not handle that. It was written to run under a 16bit OS. That means it was meant to run under either Windows v3.1 or Windows v95. Windows v98(se) or Windows vME both are 32bit OSs so even there you would run into this problem.

My solution is - download either Virtual PC from Microsoft (it is free) or download virtual Box from Oracle (it is free too) and install a copy of Windows v3.1 or Windows v95 and run the program under the OS it was meant to be run under.

Now, unfortunately, if you did not keep your Windows v3.1 or Windows v95 diskettes (or CD in Windows v95's case) then you will have to find and buy them. Or you can petition Microsoft for a copy but I do not believe they either kept them or will release them. (Unlike Apple Computer Inc. which has released, for free, DOS 3.3, ProDos, ProDos for the //gs, and Mac OSs up to version 9.x)

So this is my suggestion/answer. For Windows v3.1 and Windows v95 I would lean more towards Virtual PC as it runs under Windows XP really nicely and it also goes all the way back to just using DOS, DR DOS, and even IBM PC DOS or BDOS.

Update: 1/27/2016

To better answer SamB's question about incompatibility (which I did not say). Let's take a look at an 8bit OS. The 8bit OS expected all of the various stacks (call stack, handles, whatever) to be a certain size and to not exceed that size. When you exceeded it - you would get a blue screen of death or maybe your system would just reboot. When 16bit OSs came along the 8bit programs all acted still as if they were running on an 8bit OS system. This meant that if they exceeded the 8bit allocation size they probably would still give you a blue screen of death or your system would still just reboot. MANY companies never cared about whether or not they were crashing computers so long as the customers didn't complain about it. (Commonly called the squeaky wheel syndrome.) Microsoft tried to alleviate these problems by testing as many programs as they could for each OS but the thing is - some programs just would not work under a newer OS. My suspicion (and NOT FACT) is that some of these early stacks were jamb up against another stack so if you overflowed one stack it could adversely affect a different stack. Remember that memory was not cheap like it is today so you tried to cram as much into memory as possible. I, myself, managed many times to crash my Apple ][+ as well as my IBM PC XT simply because I caused the stack to overflow. One of the other problems is (as I said) that there were a lot of bad programmers out there who did not care one bit about cleaning up their programs. So they would allocate memory, stack memory, handles, and all sorts of other things and not release them. Your only hint that this was happening is that your computer would start to run slower and slower until you rebooted it. Rebooting would clear everything out of memory, give all of that back to your OS, and you OS would then run faster again. As I said - it is similar to how TSR or Terminate and Stay Resident programs would work. In today's OSs - many times processes are isolated from other processes and the OS itself takes care of releasing memory back to the pool (as well as clearing the stack or even allocating a new stack to each process so that each process can muck around its own stack but not the OS's stack). The problem though - is older programs from like the 16bit OS era were statically oriented. So the libraries et al were included in to the program. This means it might attempt to override what the current OS is saying it can do. So a 16bit program might say "write to location XYZ" but "XYZ" is a part of the newer OS. So then you've overwritten who knows what and your system can hang or crash because of it. If you also have admin privileges - you REALLY can muck things up. Thus my suggestion to use Virtual PC, re-install the earlier OS - and run the program under the OS it was meant to run under. First - you stand a better chance to be able to run the program there and second - if it crashes all you lose is the virtual system and not your entire computer system.

But it isn't "incompatible" as much as it is "archaic". To really, really simplify you can think of it like this: 8bits = 8K stacks, 16bit = 16K stacks, 32bit = 32K stacks, and so forth. It isn't accurate but it does get across that the different OSs used different sizes for everything. Which is why you have problems when you take something from one OS to another.

Does that make sense?

share|improve this answer
    
Er, do you have any sources for the idea that earlier versions of Windows might allocate Win16-incompatible handles? – SamB Jan 26 at 21:26
    
I did not say "incompatible" I said "32bit OSs use up all of the first 16K for handles." This particular problem started showing up for me on Windows 98se. There used to be a write-up on this and one of the things mentioned there is - once allocated, the handles for 16bit programs are not released properly. Almost like a TSR program. So, for instance, I ran the old Microsoft 16bit game Tetris. I ran it, did some stuff, ran it again, did some stuff, and then it wouldn't run. Also, my system became slower and slower. I'm running XP. Rebooting cleared things out again. – Mark Manning Jan 28 at 0:58
    
This is the same kind of problems 8bit OSs had once everyone went to 16bit OSs. The 8bit OSs were expecting things to be a certain way but 16BIT OSs expected everything to be done in a different way. So if you ran 8Bit programs that expected to run on 8Bit OSs - they could run into trouble with how a 16bit OS was set up. The same is true for 16 and 32 and 32 and 64. It is why some 32Bit programs just won't work on 64Bit OS systems. – Mark Manning Jan 28 at 1:05
    
I have to correct my last sentence. It is ONE OF THE REASONS why some 32Bit programs just won't work on 64Bit OS systems. There are other reasons too like incompatible libraries, different/updated ways to call routines, new libraries not available under the earlier OS (Like Windows XP can't do Direct 2D) and so forth. – Mark Manning Jan 28 at 1:33
    
Sorry but your explanation makes no sense. NTVDM runs in a 32-bit process and provides a full 16-bit environment to a 16-bit app. It does not matter AT ALL how much other stuff is running in your 32-bit Windows system, because all that other stuff is in other processes, i.e. completely different address spaces. And your notion that 32 bits implies 32K stacks... oh my. (User mode stacks in the NT family are up to 1 MB by default, but can be larger... or smaller.) – Jamie Hanrahan Jan 28 at 2:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .