Taskman dont work in XP-Pro

[casey.o]

This is a fairly new install of XP-Pro on my laptop. The install is to
NTFS. It's not activated since this is the wrong OEM, but everything
else works. But I click on taskman.exe and nothing happens. What would
cause that?

Also, is it normal for chkdsk not to run immediately. I go to the
command line, type chkdsk c:\ /f I get a message saying something
about a process running, and do I want chkdsk to run the next time I
restart the computer Y/N. If I choose "Y" and reboot, it does run when
it restarts. I did some googling about this, and it seems to be fairly
common, but I dont recall having this happen on other machines with XP.
However most of my other installs have been XP-Home on a Fat32 format.
Maybe that matters????

Thanks

 

[Paul]

This is a fairly new install of XP-Pro on my laptop. The install is to
NTFS. It's not activated since this is the wrong OEM, but everything
else works. But I click on taskman.exe and nothing happens. What would
cause that?

Also, is it normal for chkdsk not to run immediately. I go to the
command line, type chkdsk c:\ /f I get a message saying something
about a process running, and do I want chkdsk to run the next time I
restart the computer Y/N. If I choose "Y" and reboot, it does run when
it restarts. I did some googling about this, and it seems to be fairly
common, but I dont recall having this happen on other machines with XP.
However most of my other installs have been XP-Home on a Fat32 format.
Maybe that matters????

Thanks

http://askleo.com/why_is_my_task_manager_disabled_and_how_do_i_fix_it/

There is a registry edit in there you can use. Look for DisableTaskMgr.
In addition, it's possible to remove the decorations from the
outside of the Taskmgr window. So there are at least two things
that can screw up on it.

The only reason for a non-domain user such as yourself to be
seeing this problem, is malware. Malware loves to disable TaskMgr,
so you cannot kill any running processes.

*******

You can't CHKDSK with the intention of repairing something,
on the running C:. Upon a reboot, the C: partition
can be processed by CHKDSK, before it is used by any other software.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\BootExecute

autocheck autochk *

The single line, is the "nominal" bootexecute statement. It
would do an immediate CHKDSK if the dirty bit was set on
a partition.

When a user "schedules" a CHKDSK, without the dirty bit being
used, it adds a line to that item. So there is some kind
of explicit line requesting CHKDSK of C:.

HTH,
Paul

 

[casey.o]

http://askleo.com/why_is_my_task_manager_disabled_and_how_do_i_fix_it/

There is a registry edit in there you can use. Look for DisableTaskMgr.
In addition, it's possible to remove the decorations from the
outside of the Taskmgr window. So there are at least two things
that can screw up on it.

The only reason for a non-domain user such as yourself to be
seeing this problem, is malware. Malware loves to disable TaskMgr,
so you cannot kill any running processes.

Doing a quick scan with Security Essentials, found no malware. I'm
doing a full scan now, but that will take awhile.

Anyhow, inside of Process Hacker, there is a "click to run Task
Manager". It works fine from there, just not direct. There is an
option in Process Hacker to replace taskman, but that is NOT enabled. I
do wonder if that program disabled Taskman anyhow. Just thought I'd
update the latest find on this.....

 

[JJ]

Doing a quick scan with Security Essentials, found no malware. I'm
doing a full scan now, but that will take awhile.

Anyhow, inside of Process Hacker, there is a "click to run Task
Manager". It works fine from there, just not direct. There is an
option in Process Hacker to replace taskman, but that is NOT enabled. I
do wonder if that program disabled Taskman anyhow. Just thought I'd
update the latest find on this.....

Um... Since Windows 2000, Task Manager's EXE file is taskmgr.exe, not
taskman.exe. taskman.exe was Windows 3's legacy task manager for older
Windows version which is equivalent to XP Task Manager's "Applications" tab
(only that tab). Ironically, it requires registration of the CTRL-ESC hotkey
into the system which is already been registered by the Explorer's desktop
for the Start Menu hotkey. So, it always fails on its initialization phase.
It looks like this when it doesn't fail:

http://i.imgur.com/Rri7MMW.jpg

If pressing CTRL-SHIFT-ESC brings up Process Hacker or any other than the
Task Manager, it means that program has replaced the default Windows task
manager. If so, check that program's settings. For Process Hacker, it on:

Hacker > Options > Advanced > Replace Task Manager with Process Hacker

 

[casey.o]

Um... Since Windows 2000, Task Manager's EXE file is taskmgr.exe, not
taskman.exe. taskman.exe was Windows 3's legacy task manager for older
Windows version which is equivalent to XP Task Manager's "Applications" tab
(only that tab). Ironically, it requires registration of the CTRL-ESC hotkey
into the system which is already been registered by the Explorer's desktop
for the Start Menu hotkey. So, it always fails on its initialization phase.
It looks like this when it doesn't fail:

http://i.imgur.com/Rri7MMW.jpg

If pressing CTRL-SHIFT-ESC brings up Process Hacker or any other than the
Task Manager, it means that program has replaced the default Windows task
manager. If so, check that program's settings. For Process Hacker, it on:

Hacker > Options > Advanced > Replace Task Manager with Process Hacker

Ok, that solves the whole problem. I'm used to TASKMAN.EXE in Win98. I
typed taskmgr in XP and it popped right up. But there is also a
TASKMAN.EXE in XP (in WINDOWS and SYSTEM32 dirs). What the heck is that
for? It does nothing.

Thanks

 

[JJ]

Ok, that solves the whole problem. I'm used to TASKMAN.EXE in Win98. I
typed taskmgr in XP and it popped right up. But there is also a
TASKMAN.EXE in XP (in WINDOWS and SYSTEM32 dirs). What the heck is that
for? It does nothing.

I've already explain it at the first paragraph of my reply up to the
screenshot link. What it is, and why it doesn't work.

I just double checked. The CTRL-ESC hotkey is actually registered by the
system and not by the desktop EXPLORER.EXE process. So, even though I've
closed it including all other EXPLORER.EXE process, TASKMAN.EXE still unable
to register its CTRL-ESC hotkey. Conclusion: TASKMAN.EXE is a DOA program in
Windows 2000+.

 

[J. P. Gilliver (John)]

(Here too. 15K, IIRR.)

I've already explain it at the first paragraph of my reply up to the
screenshot link. What it is, and why it doesn't work.

I just double checked. The CTRL-ESC hotkey is actually registered by the
system and not by the desktop EXPLORER.EXE process. So, even though I've
closed it including all other EXPLORER.EXE process, TASKMAN.EXE still unable
to register its CTRL-ESC hotkey. Conclusion: TASKMAN.EXE is a DOA program in
Windows 2000+.

So, as Casey asks, what's it for (i. e. why is it there, and in two
places at that)? I had a look at it in hex, and it contains strings that
sound reminiscent of task manager.

 

[JJ]

(Here too. 15K, IIRR.)


So, as Casey asks, what's it for (i. e. why is it there, and in two
places at that)? I had a look at it in hex, and it contains strings that
sound reminiscent of task manager.

Well, it IS Windows 3 task manager. It's still there for Windows 3
compatibility, just like PROGMAN.EXE. TASKMAN.EXE is practically made
obsolete by TASKMGR.EXE.

 

[J. P. Gilliver (John)]

On Tue, 10 Jun 2014 09:54:10 -0400, (e-mail address removed) wrote: []
Ok, that solves the whole problem. I'm used to TASKMAN.EXE in Win98. I
typed taskmgr in XP and it popped right up. But there is also a
TASKMAN.EXE in XP (in WINDOWS and SYSTEM32 dirs). What the heck is that

(Here too. 15K, IIRR.)

for? It does nothing.

I've already explain it at the first paragraph of my reply up to the
screenshot link. What it is, and why it doesn't work.

I just double checked. The CTRL-ESC hotkey is actually registered by the
system and not by the desktop EXPLORER.EXE process. So, even though I've
closed it including all other EXPLORER.EXE process, TASKMAN.EXE still unable
to register its CTRL-ESC hotkey. Conclusion: TASKMAN.EXE is a DOA program in
Windows 2000+.

So, as Casey asks, what's it for (i. e. why is it there, and in two
places at that)? I had a look at it in hex, and it contains strings that
sound reminiscent of task manager.

Well, it IS Windows 3 task manager. It's still there for Windows 3
compatibility, just like PROGMAN.EXE. TASKMAN.EXE is practically made
obsolete by TASKMGR.EXE.

(a) except it doesn't seem to _do_ anything when run.
(b) what sort of "compatibility"?
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"Knowledge isnt elitist - that's rubbish! Why are we embarrassed by the idea
that people know things? It's not a conspiracy against the ignorant. Knowing
things is good!" - Jeremy Paxman, RT 14-20 August 2010

 

[JJ]

(a) except it doesn't seem to _do_ anything when run.

It does, up to registering the CRTL-ESC hotkey, which it'll always fail in
Windows 2000+.

(b) what sort of "compatibility"?

For (limited) compatibility with third party Windows 3 programs, since
Windows XP 32-bit can run them.

 

[casey.o]

http://askleo.com/why_is_my_task_manager_disabled_and_how_do_i_fix_it/

There is a registry edit in there you can use. Look for DisableTaskMgr.
In addition, it's possible to remove the decorations from the
outside of the Taskmgr window. So there are at least two things
that can screw up on it.

The only reason for a non-domain user such as yourself to be
seeing this problem, is malware. Malware loves to disable TaskMgr,
so you cannot kill any running processes.

*******

You can't CHKDSK with the intention of repairing something,
on the running C:. Upon a reboot, the C: partition
can be processed by CHKDSK, before it is used by any other software.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\BootExecute

autocheck autochk *

The single line, is the "nominal" bootexecute statement. It
would do an immediate CHKDSK if the dirty bit was set on
a partition.

When a user "schedules" a CHKDSK, without the dirty bit being
used, it adds a line to that item. So there is some kind
of explicit line requesting CHKDSK of C:.

HTH,
Paul

I cant see how I could have any malware on this new install, and I do
have Security Essentials running (even if it's no longer updated). But
anything is possible I guess. Both Precess Explorer and Process Hacker
work (which are very similar), so I really dont need Taskman, but I will
go into the registry and fix it anyhow. I'll probably be formatting
this drive soon anyhow, because I have a legitimate XP-Pro Cd coming,
but I was curious why....

So, in other words I could CHKDSK any other partition, just not C:.
This is the only computer that only has one partition. because it only
has a 40meg drive. Laptop HDDs are costly.

Thanks

 

[Paul]

I cant see how I could have any malware on this new install, and I do
have Security Essentials running (even if it's no longer updated). But
anything is possible I guess. Both Precess Explorer and Process Hacker
work (which are very similar), so I really dont need Taskman, but I will
go into the registry and fix it anyhow. I'll probably be formatting
this drive soon anyhow, because I have a legitimate XP-Pro Cd coming,
but I was curious why....

So, in other words I could CHKDSK any other partition, just not C:.
This is the only computer that only has one partition. because it only
has a 40meg drive. Laptop HDDs are costly.

Thanks

Of course you can CHKDSK C:.

Just not while C: is "online".

The OS uses an opportunity early in the boot cycle, to
do the CHKDSK then. You can schedule the CHKDSK
to be run - an attempt to do CHKDSK of C: with repair selected,
it should ask you whether you want to do it on the next reboot.
In which case, the bootexecute registry key is modified
so it gets done next time. So all it takes is a reboot.
And as for an "interface", there should be an event in
Event Viewer with the word "winlogon" in it, and that
event will have the text from the CHKDSK run. It works
that way, because the OS isn't really running while the
CHKDSK is being done, so the text is stored for later.
And the Event Viewer is where you get to find out if
there was any serious repair work (or CHKDSK is stuck
in a loop etc).

The other way, is to use FSUTIL utility to set the dirty
bit on the partition. A dirty partition gets checked at
startup as well. I used that technique, when my Windows 8
disk "disappeared" one day (unclean dismount results),
and I used FSUTIL to set the dirty bit on all the affected
partitions. It was an attempt to get Windows 8 to clean up
the mess, the next time Windows 8 was booted. Only I discovered,
that Windows 8 doesn't care about the dirty bit, and the
dirty bit was only recognized later when I ran CHKDSK
manually. It works a bit more reasonably (logically) on
WinXP.

A "dirty" partition should be checked immediately,
because the OS doesn't know how the bit got there, and it
is a bit presumptuous to assume the partition is "healthy"
at that point in time. Windows 8 has a different "health" system
than WinXP, and Windows 8 "tends to the disk continuously".
So there is background activity that duplicates some of
what CHKDSK would do (integrity checking). WinXP is the
"DIY maintenance" OS - a feature I like, because I feel
like I'm in control. Whereas Windows 8 does whatever it
feels like, whenever it feels like doing it.

Paul

 

[Paul]

I wonder if after doing this, he'll also need to reset the dirty bit
subsequentally?
I seem to recall having to do this by running "chkntfs" to prevent chkdsk
from continually running and delaying the boot up times (viz, there would
(otherwise) be a few minutes of unnecessary disk activity after each
reboot). Am I the only one that has run into this glitch?

The dirty bit is unidirectional. FSUTIL can set the dirty bit,
but not clear it. It's a way of waving a red flag and saying
"this partition needs a CHKDSK". The location of the dirty bit,
is not documented on purpose, so people won't be flipping it back
(When you're stuck in a loop, people are sorely tempted to do that.)

CHKDSK knows how to clear the dirty bit, and since the flag
is a "signal to CHKDSK", it is perfectly appropriate for
CHKDSK to be the only one who knows how to clear the bit.

Paul

 

[BillW50]

The dirty bit is unidirectional. FSUTIL can set the dirty bit,
but not clear it. It's a way of waving a red flag and saying
"this partition needs a CHKDSK". The location of the dirty bit,
is not documented on purpose, so people won't be flipping it back
(When you're stuck in a loop, people are sorely tempted to do that.)

CHKDSK knows how to clear the dirty bit, and since the flag
is a "signal to CHKDSK", it is perfectly appropriate for
CHKDSK to be the only one who knows how to clear the bit.

I use Hard Disk Sentinel v2.81 (unregistered version). And under
Advanced Options you can "Disable automatic scandisk upon start of
Windows" or "Delay before starting scandisk (seconds)". I think that was
the last version without nags or PUPs.

Well I am not sure how it works, but one machine I had would always scan
the drive at boot and CHKDSK never found anything, but would still check
at every boot. I think it was on a dual boot machine come to think about
it. Another reason I hate dualboot systems! But Hard Disk Sentinel cured
it and I didn't have to worry about that problem anymore.

 

[casey.o]

Well I am not sure how it works, but one machine I had would always scan
the drive at boot and CHKDSK never found anything, but would still check
at every boot. I think it was on a dual boot machine come to think about
it. Another reason I hate dualboot systems! But Hard Disk Sentinel cured
it and I didn't have to worry about that problem anymore.

--

I've never had that happen on my Win98 / Win2000 dual boot machine. But
maybe XP and newer OSs are different in that regard. Now if I lose
power during due to a storm or other reason, then I might get a scandisk
at boot, but there is a reason for it, and once it's run, it's done.

 

[BillW50]

I've never had that happen on my Win98 / Win2000 dual boot machine. But
maybe XP and newer OSs are different in that regard. Now if I lose
power during due to a storm or other reason, then I might get a scandisk
at boot, but there is a reason for it, and once it's run, it's done.

It happened on an XP machine that had a dualboot with Windows 7 Preview.
And I believe how it worked was every time you booted to 7, the XP
partition would be set as dirty (and CHKDSK would never find anything
wrong with it). I later dumped Windows 7 and all was well once again
except for below.

I did end up with two odd problems after this. One Paragon Drive Copy
v11 analyzes the drive before cloning and it doesn't care how it is
setup to boot, it somehow detects Windows 7 there and sets it up to boot
Windows 7 instead of XP (it thinks it is doing me a favor). There isn't
a single Windows 7 file anywhere anymore that I could find. But
Paragon's log says Windows 7 is there and even knows the correct build
number that used to be there. Go figure!

The second oddity is that Maxthon v3 doesn't remember passwords on this
machine. I haven't really investigate this problem much since that
machine is mainly used for TV recording and a huge amount of games. And
I hardly ever go online with it since it doesn't need anything online
anyway.