user.exe and stack faults

[Chris Boss]

I am trying to solve a problem with a PB program running on Windows 95/98. It works fine on Windows ME to Vista.

The program crashes with an error message:

Stack Fault in User.exe

I have done some research on this and it is very confusing.

First, the program never makes any calls to user.exe.

Second, user.exe appears to be some kind of link between 16 bit Windows and 32 bit (it was the 16 bit version of user32.dll if I understand it correctly).

My impression is that Windows is running something (ie. driver) in 16 bit code and when the API is called, windows reverts to some 16 bit code somewhere and crashes.

I have no idea of where to start.

MSDN is useless. When I search MSDN I get references to a number of bugs in a variety of software (even Visual Basic) which generates the stack fault in user.exe. What is very strange is the solutions for each bug. The solutions for VB apps make absolutely no sense (ie. change a line of code, which is nornally acceptable to something different). In VB things like a combobox in the wrong place (on another control) can cause this error.

The thing is, what does user.exe have to do with all of this ?

It is not user32.dll

It almost appears that Windows does some workarounds internally and is reverting back to 16 bit code and this causes problems. It is as if even Microsoft doesn't really understand what is going wrong. The fixes almost appear to be quesses, rather knowledgable answers.

One example was Windows ME crashing when being installed (stack fault in user.exe) and the cause suggested was "bad memory chips" (or not seated correctly).

I need to understand what this user.exe is really doing in the operating system and why it crashes, even when apps never even call it directly. I used the depends utility to test for dependencies (on XP) and I don't see anywhere user.exe is even referenced.

[Mike Stefanik]

First, allow me to make the obligatory comments about using an operating system that is over 12 years old and is an inherently unstable monstrosity of 16-bit and 32-bit code. People should no more be using Windows 95/98 today than they should be driving a Ford Pinto with a leaking gas tank. 'Nuff said.

The misunderstanding that I think you're fundamentally having is reflected in this quote:

It almost appears that Windows does some workarounds internally and is reverting back to 16 bit code and this causes problems.

It's not a workaround. At its core, Win9x is still a 16-bit operating system running in protected mode. User.exe is the 16-bit module that handles drawing windows, handling user input and all the rest. User32.dll is the 32-bit module that most folks are familiar with, but on Win9x, if you look at User32.dll it really doesn't do much; it's mostly a 32-bit shim that exports functions that thunk down to the 16-bit code that actually does the work in User.exe. This is why on Win9x, you still have resource limitations because of the fixed USER and GDI heap sizes. (And you'll notice, User.exe is about 500K, while User32.dll is about 70K).

Bottom line, if you're making calls to User32.dll, you're indirectly making calls to the 16-bit User subsystem in User.exe. You won't see it referenced because it's not a 32-bit PE module, but it's being used. The culprit could be a lot of things, from exceeding the maximum number of handles, device contexts, fonts or brushes (as could be the case with a resource leak), to having too many items in a listbox or specifying a resource (such as an image) that is too large. The first thing I would try is a resource monitor and see what percentage of your system resources are in use, and if resource utilization continues to increase as your application runs. When more than 90% of the or USER or GDI heaps are in use, Win9x can become unstable and you start seeing a lot of bizzare behavior.

Of course, the real answer could also be like the patient who goes to the doctor and says "Doc, I don't know what's wrong, but when I move my arm like this (starts waving it up and down), it really hurts." The doctor says, "That's simple to fix -- just don't do that." Just don't support antique operating systems like Windows 95/98, and the problem is solved.

[Cliff Nichols]

Can you post code? Or at least a link to the exe?
I am sure someone can spot some points that could be possible causes.

[Chris Boss]

I solved the problem!

It appears Win95/98 is not so forgiving of certain API calls being made at certain times. The user.exe error message is what threw me since I had no idea of what would cause that.

I put debug code in my app section by section in areas where the app was crashing until I found the offending line of code.

The problem was:

a call to SetFocus during code being executed in the WM_CREATE message. The code was attempting to set the focus to the parent dialog (form) before creating the controls.

As far as working with earlier operating systems, my software was purposely designed to be run on all versions of Windows from 95 to Vista.

I have good reasons for this.

[Cliff Nichols]

As far as working with earlier operating systems, my software was purposely designed to be run on all versions of Windows from 95 to Vista.

I have good reasons for this.

And that would beeeeeeee?????

Oh wait, you are one of "Those type of guy" (like me) that has End Users that do not know that all M$ operating systems prior to XP no longer exist.

You would NOT believe comments I have gotten when I tell a user that the problem is their operating system and they can not do what they want to do with that particular OS.

Luckily to date, with the exception of 1 person that demands I Re-Write a dll of mine because he claims a bug causing a crash under Vista. (One I can not replicate) that I have been able to keep all OS'es from 95 and up running the same software.

[Chris Boss]

I develop software tools for other programmers and while many do not need to support older versions of Windows (and they tell me so), some do benefit from the ability to write software for legacy PC's.

If you are writing software for a large manufacturing company, there are usally many legacy PC's inhouse and to be able to write software which will run on those PC's makes a big difference and saves a lot of money (and resources).

I have a lot of experience in writing custom software for local businesses and you would be surprised how many would prefer to hold on to existing hardware, rather than always purchase new PC's.

I would think that today with all the problems with the worldwide economy, people would appreciate being able to save money by holding ontol legacy systems.

Even if 90% of my customer base doesn't care about writing software for legacy systems, the small percentage who do are still important.

I also have strong feelings about not wasting valuable assets and my software reflects that.

I get around problems with supporting older versions of Windows, while still getting the most out of later versions by polling Windows to see what version it is and if a later version is used, making those newer features available.

If supporting older systems is not important to many PB'ers that does not mean their is no value.

I don't agree with the view that one should always write software for the latest hardware as if that is all that matters.

[Mike Stefanik]

I don't agree with the view that one should always write software for the latest hardware as if that is all that matters.

Neither do I. But when you're talking about Windows 95, that operating system was released almost 13 years ago. It'd be like arguing that back in 2000 you still should have been supporting Windows 2.0. Windows 2000 and Windows XP are older operating systems; Windows 95 is positively ancient (and we won't even go into how insecure it is, god forbid it's actually hooked up to the Internet).

You should do whatever you feel is in the best interests of your customers, of course. But pushing them to get off the insecure, unstable Win9x hybrid platforms would be doing them a service in my opinion.

[Chris Boss]

If a company utilizes their computer resources effectively, likely older PC's will get pushed back to mundane tasks where they are not connected to either the internet or a network. They can be used for stand alone purposes (ie. running a machine or data retrieval).

Where security is an issue, likely new PC's are purchased.

There are plenty of tasks for standalone PC's running Windows 95. Windows 95 is a lean operating system which can run on minimum hardware.

Legacy PC's can also be used for educational purposes in schools which can not afford newer PC's.