User display in task manager

[Guest]

I am investigating some problems with DCOM and so I wanted to see the
launching User Name in the task manager. But the column User Name ist always
empty execpt for the 'System Idle Process' (which has user SYSTEM).

Has anyone an idea what is needed to see entries in the User Name column?

When I use an external tool (TaskInfo.exe www.iarsn.com), I can see the
correct User Names, so I think it is only a problem of displaying in the task
manager.

Regards,
Burkhard

 

[Guest]

Hello Burkhard,

I know that's not a answer of your question but it was difficult to find you.
2 Years ago you had a discussion with the subject "Handling NMIs on
XP/Win2003"!
I try to hook the nmi under WindowsXP/eXP but the system crash by IRETD.
I think you had found a solution of this problem? Perhaps you can help me?
What is to do after IRETD to handle KiTrap02, HalHandleNMI and BugCheck?
Thanks.

Best Regards,

Mario

 

[Guest]

Hi Mario,
Ok, some more off topic
please see the discussion, at
<http://groups.google.de/group/micro...c945?lnk=st&q=bcpauli&rnum=5#8a8863d71625c945>
there is a solution.

But the problem is the implementation of the NMI handling with a TaskGate.
There is no way in Windows XP to be sure that the state of the math Co
processor is correct after the iretd when you do it with a TaskGate ( it has
to do with the windows implementation of the INT07 and the EM-Bit handling in
CR0 by the TaskGate, remember NMIs can occure at any moment).

The only way to use NMIs, is to install a InterruptGate for the NMI and if
you want to use the FPU during NMI you have to save the FPU on entering and
restore it on before you iretd.

And be sure to disbale SMIs (System Management Interrupts), because they are
executed during an NMI and if you return from SMM the state that one NMI
can't be interuppted by another NMI is lost!

See Intel Docu "Intel Architecture Software Developer’s Manual, Volume 3:
System Programming Guide (Order Number 243192)"
Chapter 11.7 NMI HANDLING WHILE IN SMM

....
A special case can occur if an SMI handler nests inside an NMI handler and
then another NMI
occurs. During NMI interrupt handling, NMI interrupts are disabled, so
normally NMI interrupts
are serviced and completed with an IRET instruction one at a time. When the
processor
enters SMM while executing an NMI handler, the processor saves the SMRAM
state save map
but does not save the attribute to keep NMI interrupts disabled.
Potentially, an NMI could be
latched (while in SMM or upon exit) and serviced upon exit of SMM even
though the previous
NMI handler has still not completed. One or more NMIs could thus be nested
inside the first
NMI handler. The NMI interrupt handler should take this possibility into
consideration.
....

Regards,
Burkhard

 

[Guest]

Hello Burkhard,

thanks for your quick answer! Yes, I saw the solution but I don't know how
to jmp to the KiTrap02! Do you have a source code sample to handle this
problem.

Regards,

Mario

 

[Guest]

Sorry no sample.
One way is patch the right Opcode for the jmp into the kernel right behind
the iretd, but that is only for testing purpose,
because you destroy the original code in this place.
The other way is to install your own version of KiTrap02-code in a driver
(simular to the kernel code) and set the EIP entry in the NMI-TSS to point at
your code.( At least you should also install you r own stack for you NMI-Task
with the ESP0, EBP and ESP entries).
But also rememder to add a jmp to the beginning of you code behind your iretd.


bcp