Paul in Houston TX wrote:
pyotr filipivich wrote:

Okay, one for de schmart guys.

Every so often, say once or twice a week, Mailwasher.exe hangs up
at the splash screen. Just, sits there.
I've right clicked on the taskbar icon and chosen "exit", clicked
on the red x to close the window. Used Task Manager and Process
Hacker, separately, and sequentially, to attempt to kill the process.
No luck.I've logged out or selected "Restart" as the shutdown option,
and windows has hung up on the "logging out" screen. Normally a
reboot takes long enough I can go warm up a cup of coffee on the
stove, sometimes make a fresh pot. But in this case, I have time to
brew a Fresh Cup from scratch. As in go to Columbia, pick the beans
myself, dry, roast, and grind them. I'm assuming that, I haven't
waited two weeks, I just kill the power when I get back from getting
coffee.

Because until it is dead, I can't start it again.

What I am wondering is, is there a way to determine what
services/modules/handles one might be able to track, hunt down and
terminate, unload, kill, in order to closed down the process, process
tree, or whatever is holding the splashscreen / program open?

I've attempted to close modules through Process Hacker, as well as
terminate specific threads, but no change.

Is this a new "feature" I'm just going to have to live with?

tschus
pyotr

If it were me, I would first test the ram.
If ram is ok then I would remove and reinstall the program.

Windows supports "zombie" status for processes, just like some
other OSes do. That seems to have gone underground on Windows 10 again,
but I was seeing zombies (not Suspended) at some point on Win10. You
can't kill a zombie because it's waiting to be harvested. It's not
a "push" thing, you cannot push it over a cliff, the thing harvesting
it has to "pull" it, at the appropriate software moment-in-time.
Which might be never. Normally, zombie status might last for 100usec,
just after you hit the X in the corner and the program (appears to)
have stopped running. The harvesting is normally quite fast,
so you should not see a zombie status in Task Manager. It's
when that process fouls up, that the thing hangs around with a
"zombie" sign around its neck.

They kinda admit to such a thing here.

https://docs.microsoft.com/en-us/win...ugger/-zombies

A second kind of weirdness, is it's possible for a process to be
forked with no name. This makes it rather difficult to work with,
unless you have the PID for it. All it takes is two levels
of forking, to make the parentage indeterminate. The OS should
really terminate things like this, as a way to teach the
developer community what they're not allowed to do. A process
should simply not be allowed to run with an empty or a null
string associated with it for a process name.

Windows has its share of "non-conformal" things it will do, which
means that "standard" recipes to remove them won't always work. About
all I can promise you, is a reboot (clean or dirty) will resolve
it for the moment. Dirty being, hitting the power button, because
you got stuck on the "problem" one.

The same things happen with performance counters. Are performance
counters orthogonal, working under any and all circumstance ? No.
Things being counted, can be counted against processes you never expected.
It's quite easy in fact, for the disk light to be flashing on your
hard drive, and you being unable to figure out what process is
doing the writing. Not every aspect of I/O must appear in
Task Manager. Or even in Perfmon.msc window. As these things
go, the OS is "undisciplined" and refuses to get a hair cut.

When a user here says "I'm stuck", I really believe them.
You can be stuck.

Things like this wouldn't happen, if the OS had proper
checks and balances. Why does the OS design allow things
like this to happen ? That's the puzzling part.

https://www.cnet.com/forums/discussi...sses-on-win10/

Here's another one. Posted by someone who works there and
know how this stuff works.

"Why do some process stay in Task Manager after they’ve been killed?"

https://blogs.msdn.microsoft.com/old...23-00/?p=38363

"When a process ends (either of natural causes or due to something
harsher like TerminateProcess), the user-mode part of the process
is thrown away. But the kernel-mode part can't go away until all
drivers are finished with the thread, too.

For example, if a thread was in the middle of an I/O operation,
the kernel signals to the driver responsible for the I/O that
the operation should be cancelled. If the driver is well-behaved,
it cleans up the bookkeeping for the incomplete I/O and releases
the thread.

If the driver is not as well-behaved (or if the hardware that the
driver is managing is acting up), it may take a long time for it
to clean up the incomplete I/O. During that time, the driver holds
that thread (and therefore the process that the thread belongs to)
hostage.
"

"If you think your problem is a wedged driver, you can drop
into the kernel debugger, find the process that is stuck
and look at its threads to see why they aren't exiting.
"

Yes, I do that every day, right after I brush my teeth.

Paul