Antares said:
I frequently get the error message, "Program Not Responding" when I
try to save a file I'm working on, or close the program. This happens
frequently but not always. That is, about half of the time I do this
everything works as it should.
When the file save operation hangs up, if I just wait a minute or so
the program will start responding and the file will be saved, then all
goes well for a while. This is happening in all of my client software,
not just one specific program.
This is a home built computer with an ASUS P7P55D Motherboard, running
Windows 7, 64 bit Home Premium.
Memory 3.99 GB
Processor Intel Core i7
This computer has three hard drives, C, D & F. C is used for the
client software, D is used for the work files and F is used for
automated backups. Each of these drives is a Western Digital 565 GB
and they each show about 2/3 of the drive as unused space.
I certainly would appreciate any suggestions. I've tried updating all
my drivers with Driver Detective. I've also checked for on-line
updates for my OS and client software. All seem to be up to date.
Gordon
When you go to interact with the file system, and open a file dialog
box, the computer may check "well, how many file systems do I have"
and it attempts to "stat" or check the health of each one.
It could be, that a share, or some other kind of transient file system
object has gone missing, and the system is looking for it. In an
attempt to debug the problem, I'd check whether the machine had been
used to "connect to work", use a share somewhere, and that share
was gone.
Or, check how many "custom" file system objects have been installed.
For example, a "virtual CD drive" software, which mounts ISO files
and pretends they're a CD drive, is a file system object. Some of
those have weird behaviors in corner cases.
Generally speaking, as time goes on, fewer and fewer things in
Windows "run synchronous and block". Much of the OS is asynchronous,
and that helps prevent Windows from becoming jammed up. And what
that means in practice, is to as much an extent as possible,
the system should never "stall in the kernel". The kernel should
return calls from application programs, in a timely manner, without
preventing other kernel calls from being handled.
To give an example of a violation of this principle, look back at
Windows 98 and the networking stack. I had quite a few examples
there, where I could be doing something network related, and
the system would freeze up temporarily. And it's because some
network code would "block" and wait for a result, and something
would eventually time out, and release the system back to me.
While blocked, the computer would be virtually useless.
It's pretty hard for the software designers, to remove all cases
of that. They work on them as they find them, and sometimes
the problems disappear, because the entire architecture has
been redone from top to bottom. (In the case of vista,
that "redo" caused more problems than it solved. Windows 7
allowed some time to pass, for cleanup.)
*******
There have been cases, where the "jam up" thing was constant.
There was one chipset (possibly by SIS), where if you attempted
to do any operation on a disk drive, there was a five second
delay. Nothing would happen. Task Manager would not be "busy"
and no cycles were wasted. It was like some portion of the
driver for the disk, simply didn't receive the command. After
five seconds, the lost command would time out, and some layer
of the storage stack would "retry" the operation, and it would
always succeed. I never did hear back from anyone affected,
whether that ever got fixed. That's a bug, somewhere between
OS and driver, and can be really annoying, because any attempt
to access a disk, is met with a guaranteed five second delay,
before the disk hears of the command. I've never experienced
that here, but can imagine that would be annoying.
If you're the kind of person, that "installs a new program
every day", tries every piece of cruft imaginable (I used
to do that with my Macintosh computer
), then there
are bound to be the odd side effect from doing so. Normally
we'd say to "simply your setup" or eliminate what we'd
call "suspicious things". For example, if you saw nothing
but bad comments about Norton GoBack, and you had a copy,
you might focus on that. Your file system, differs from
ours in some way, and the trick is figuring out, how
it differs. You've added something to your system,
that we're not using.
*******
Let's take a hypothetical case. I have a Windows 7 laptop.
Say I started having your problem. How would I attack it ?
One test case I'd try would be:
1) Image the system to an external drive. An exact copy,
so the problem situation can be restored in step (4).
2) Do a "factory reset" using the Acer OEM restore partition
that came with the laptop.
3) Install some client program that used to have a problem.
Test whether the delay/freeze is there.
4) (Restore the image when you're finished testing, to bring
the system back to where it was.)
That's an example of simplifying the system, and it removes
everything suspicious. If that test case fails (problem
still present), it could be a hardware problem, such as
a failing disk drive.
Examples of softwares, that might run synchronous with user
activity, would be AV software (scanning the same file you're
trying to work on), perhaps System Restore (making a backup
copy of something). It could be some program like that, which
is responsible. If you have a boatload of anti-malware
programs, perhaps they're all "piling on" when you do a
file system operation.
Paul
