Prev: Allow RemoteApp but Disable Desktop (2008)
Next: The server failed to retrieve the SID of Session BRoker
From: jolteroli on 4 Nov 2008 16:52
Not sure if this will help...

If you look in proc-explorer on the threads-tab in the csrss process, you
should find a thread causing all this IO and having a pretty high
cpu/context-switch-delta value.

If you suspend this thread does the IO drop? (Do this on the csrss of a
test-user session)

What is the "starting address" and the call [Stack] of the thread?

-jolt

"rpremuz" <rpr.nospam(a)gmail.com> schrieb im Newsbeitrag
news:d584c509-0cb1-4bb5-af9b-65b905a84bd0(a)p31g2000prf.googlegroups.com...
On Nov 3, 7:49 pm, "jolteroli" <jolt1...(a)gmx.net> wrote:
> Do the session, the "freaking csrss" belongs to, also have a process named
> "ntvdm" running?

There is no ntvdm process running on the server.

-- rpr.

From: rpremuz on 5 Nov 2008 08:27
On Nov 4, 10:52 pm, "jolteroli" <jolt1...(a)gmx.net> wrote:
>
> If you look in proc-explorer on the threads-tab in the csrss process, you
> should find a thread causing all this IO and having a pretty high
> cpu/context-switch-delta value.
>
> If you suspend this thread does the IO drop? (Do this on the csrss of a
> test-user session)
>
> What is the "starting address" and the call [Stack] of the thread?

The thread of csrss.exe with the highest CSwitch Delta has the
following start address: winsrv.dll!ConServerDllInitialization+0x5866

If the thread is suspended, the I/O drops but the terminal session
screen freezes (no animation) and it becomes unresponsive to keyboard
and mouse inputs. If the thread is resumed (from the Process Explorer
running in another terminal session), the terminal session unfreezes
and high I/O problem starts again.

The call stack of the thread is the following:
0 ntoskrnl.exe+0x397ea
1 ntoskrnl.exe+0x3df9e
2 ntoskrnl.exe+0x50675
3 ntoskrnl.exe+0x40720
4 ntoskrnl.exe+0x3f326
5 win32k.sys+0x15287
6 win32k.sys+0x6fd25
7 win32k.sys+0x98a52
8 ntoskrnl.exe+0x33bef
9 ntdll.dll!KiFastSystemCallRet

The high I/O can be induced by keyboard or mouse activity.
Here is what a little testing on a server showed for the csrss.exe
corresponding to a terminal session:
-- the terminal session window restored or maximized
+ no mouse or keyboard activity -- Other Bytes Delta: 7 MB
+ mouse activity -- Other Bytes Delta: 50 - 70 MB
+ keyboard activity -- Other Bytes Delta: 150 - 200 MB
-- the terminal session window minimized -- Other Bytes Delta: 0

If the server console is used for log on, there is no high I/O for the
corresponding csrss.exe process.

-- rpr.
From: andrea.tironi on 8 Nov 2008 10:11
Hi.

I have no solution, but same issue on three w2k3 enterprise R2 sp2.
I try patch from microsoft kb 934330 without success.

Some ideas?

Andrea


On 5 Nov, 08:27, rpremuz <rpr.nos...(a)gmail.com> wrote:
> On Nov 4, 10:52 pm, "jolteroli" <jolt1...(a)gmx.net> wrote:
>
>
>
> > If you look in proc-explorer on the threads-tab in the csrss process, you
> > should find a thread causing all this IO and having a pretty high
> > cpu/context-switch-delta value.
>
> > If you suspend this thread does the IO drop? (Do this on the csrss of a
> > test-user session)
>
> > What is the "starting address" and the call [Stack] of the thread?
>
> The thread of csrss.exe with the highest CSwitch Delta has the
> following start address: winsrv.dll!ConServerDllInitialization+0x5866
>
> If the thread is suspended, the I/O drops but the terminal session
> screen freezes (no animation) and it becomes unresponsive to keyboard
> and mouse inputs. If the thread is resumed (from the Process Explorer
> running in another terminal session), the terminal session unfreezes
> and high I/O problem starts again.
>
> The call stack of the thread is the following:
> 0 ntoskrnl.exe+0x397ea
> 1 ntoskrnl.exe+0x3df9e
> 2 ntoskrnl.exe+0x50675
> 3 ntoskrnl.exe+0x40720
> 4 ntoskrnl.exe+0x3f326
> 5 win32k.sys+0x15287
> 6 win32k.sys+0x6fd25
> 7 win32k.sys+0x98a52
> 8 ntoskrnl.exe+0x33bef
> 9 ntdll.dll!KiFastSystemCallRet
>
> The high I/O can be induced by keyboard or mouse activity.
> Here is what a little testing on a server showed for the csrss.exe
> corresponding to a terminal session:
> -- the terminal session window restored or maximized
>   + no mouse or keyboard activity -- Other Bytes Delta: 7 MB
>   + mouse activity -- Other Bytes Delta: 50 - 70 MB
>   + keyboard activity -- Other Bytes Delta: 150 - 200 MB
> -- the terminal session window minimized -- Other Bytes Delta: 0
>
> If the server console is used for log on, there is no high I/O for the
> corresponding csrss.exe process.
>
> -- rpr.

From: jolteroli on 9 Nov 2008 06:36
Hey Robert,

I don't want bother you, but you've not configured symbols. If you want to
have them:

1.) Install latest windbg.
2.) Copy latest dbghelp.dll (in the windbg directory) to system32
3.) Create a directory for symbol files, e.g.: f:\symbols
4.) Set system-wide environment variable:
_NT_SYMBOL_PATH=SRV*f:\symbols*http://msdl.microsoft.com/download/symbols
5.) Download symbols for a single image by:
symchk c:\winnt\system32\winsrv.dll
symchk c:\winnt\system32\csrss.exe
symchk c:\winnt\system32\win32k.sys
symchk c:\winnt\system32\ntkrnpa.exe
symchk c:\winnt\system32\ntdll.dll
... and so on...
Or download any image in system32 recursively:
symchk /r c:\winnt\system32\*
6.) In the Process Explorer, configure the symbol path, to f:\symbols

You can put
dbgeng.dll
dbghelp.dll
SymbolCheck.dll
symchk.exe
symsrv.dll
on a USB pen. So you don't need the Debugging Tools any time.

If you now view the threads and their stack trace, it might look like:

winsrv.dll!StartCreateSystemThreads:
ntkrnlpa.exe!KiSwapContext+0x2f
ntkrnlpa.exe!KiSwapThread+0x8a
ntkrnlpa.exe!KeWaitForMultipleObjects+0x284
win32k.sys!RawInputThread+0x4f3
win32k.sys!xxxCreateSystemThreads+0x60
win32k.sys!NtUserCallOneParam+0x23
ntkrnlpa.exe!KiFastCallEntry+0xfc
ntdll.dll!KiFastSystemCallRet
winsrv.dll!NtUserCallOneParam+0xc

And you can see which functions are involved in the freaking thread. I would
start and view the stack traces

Once, when the RDP window is minimized has no IO
Once, when the RDP window is maximized and produce IO

Any difference?

-jolt

From: rpr on 12 Nov 2008 14:30
Hi, jolteroli!

As you suggested I installed Debugging Tools for Windows 32-bit
Version
(from http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx
).
To replace "%SystemRoot%\system32\dbghelp.dll", which is in use by
some running processes, with the newer version in
"%ProgramFiles%\Debugging Tools for Windows (x86)\" you need to use
one of the methods explained at http://support.microsoft.com/kb/181345

Then I run the following commands:
mkdir c:\windows\symbols

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager
\Environment" /v _NT_SYMBOL_PATH /d "SRV*c:\windows\symbols*http://
msdl.microsoft.com/download/symbols" /f

"%ProgramFiles%\Debugging Tools for Windows (x86)\symchk.exe"
"%SystemRoot%\system32\winsrv.dll"

"%ProgramFiles%\Debugging Tools for Windows (x86)\symchk.exe"
"%SystemRoot%\system32\csrss.exe"

"%ProgramFiles%\Debugging Tools for Windows (x86)\symchk.exe"
"%SystemRoot%\system32\ntoskrnl.exe"

"%ProgramFiles%\Debugging Tools for Windows (x86)\symchk.exe"
"%SystemRoot%\system32\win32k.sys"

"%ProgramFiles%\Debugging Tools for Windows (x86)\symchk.exe"
"%SystemRoot%\system32\ntdll.dll"

After restarting the server I got the following data from
Process Explorer regarding my problem:

When the RDP window is minimized, the I/O is normal.
The thread of csrss.exe with the highest CSwitch Delta has the
following start address: winsrv.dll!StartCreateSystemThreads

The call stack of the thread is the following:
ntoskrnl.exe!KiSwapContext+0x26
ntoskrnl.exe!KiSwapThread+0x2e5
ntoskrnl.exe!KeWaitForSingleObject+0x346
ntoskrnl.exe!KiSuspendThread+0x18
ntoskrnl.exe!KiDeliverApc+0x117
ntoskrnl.exe!KiSwapThread+0x300
ntoskrnl.exe!KeWaitForMultipleObjects+0x3d7
win32k.sys!RawInputThread+0x4e0
win32k.sys!xxxCreateSystemThreads+0x60
win32k.sys!NtUserCallOneParam+0x23
ntoskrnl.exe!KiFastCallEntry+0xfc
ntdll.dll!KiFastSystemCallRet
winsrv.dll!NtUserCallOneParam+0xc

When the RDP window is restored or maximized, the I/O is very high.
But the thread of csrss.exe with the highest CSwitch Delta has the
start address and call stack as above (no difference when compared to
the normal state).

Does this tell you anything? To me it tells nothing as I don't have
the sources :-| (Almost a complete waste of time.)

-- rpr.


On Nov 9, 12:36 pm, "jolteroli" <jolt1...(a)gmx.net> wrote:
> Hey Robert,
>
> I don't want bother you, but you've not configured symbols. If you want to
> have them:
>
> 1.) Install latest windbg.
> 2.) Copy latest dbghelp.dll (in the windbg directory) to system32
> 3.) Create a directory for symbol files, e.g.: f:\symbols
> 4.) Set system-wide environment variable:
>     _NT_SYMBOL_PATH=SRV*f:\symbols*http://msdl.microsoft.com/download/symbols
> 5.) Download symbols for a single image by:
>         symchk c:\winnt\system32\winsrv.dll
>         symchk c:\winnt\system32\csrss.exe
>         symchk c:\winnt\system32\win32k.sys
>         symchk c:\winnt\system32\ntkrnpa.exe
>         symchk c:\winnt\system32\ntdll.dll
>         ... and so on...
>     Or download any image in system32 recursively:
>         symchk /r c:\winnt\system32\*
> 6.) In the Process Explorer, configure the symbol path, to f:\symbols
>
>     You can put
>         dbgeng.dll
>         dbghelp.dll
>         SymbolCheck.dll
>         symchk.exe
>         symsrv.dll
>     on a USB pen. So you don't need the Debugging Tools any time.
>
> If you now view the threads and their stack trace, it might look like:
>
> winsrv.dll!StartCreateSystemThreads:
>   ntkrnlpa.exe!KiSwapContext+0x2f
>   ntkrnlpa.exe!KiSwapThread+0x8a
>   ntkrnlpa.exe!KeWaitForMultipleObjects+0x284
>   win32k.sys!RawInputThread+0x4f3
>   win32k.sys!xxxCreateSystemThreads+0x60
>   win32k.sys!NtUserCallOneParam+0x23
>   ntkrnlpa.exe!KiFastCallEntry+0xfc
>   ntdll.dll!KiFastSystemCallRet
>   winsrv.dll!NtUserCallOneParam+0xc
>
> And you can see which functions are involved in the freaking thread. I would
> start and view the stack traces
>
>     Once, when the RDP window is minimized has no IO
>     Once, when the RDP window is maximized and produce IO
>
> Any difference?
>
> -jolt
 |  Next  |  Last
Pages: 1 2
Prev: Allow RemoteApp but Disable Desktop (2008)
Next: The server failed to retrieve the SID of Session BRoker