Re: Unhandled exception when pushing esi

In some circumstances (in particular if a thread has been converted to a GUI
thread by making a call to win32k.sys), the kernel stack will be grown to be
larger than 12K.

For example:

lkd> !thread 8883e8f0 f
THREAD 8883e8f0 Cid 0fec.484c Teb: 7ffdd000 Win32Thread: e6939008 RUNNING
on processor 0
Not impersonating
DeviceMap e976c1b0
Owning Process 880f7020 Image: windbg.exe
Wait Start TickCount 8323115 Ticks: 7 (0:00:00:00.109)
Context Switch Count 734 LargeStack
UserTime 00:00:00.0390
KernelTime 00:00:00.0062
Start Address 0x7c810856
Win32 Start Address 0x01029120
Stack Init 9cfd3000 Current 9cfd2d34 Base 9cfd3000 Limit 9cfcf000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 16

(16K stack size here on an x86 system.)

"David J. Craig" <Dave@xxxxxxxxxxxxx> wrote in message
news:eaI60yfgGHA.356@xxxxxxxxxxxxxxxxxxxxxxx
12KB is not the 'usual', it is the fixed unchanging size. 16KB on x64.
The kernel guys said that it would not be increased according to Microsoft
at one of the IFS PlugFests.


"Skywing" <skywing_NO_SPAM_@xxxxxxxxxxxxxxxxxxx> wrote in message
news:uW7IaPfgGHA.4276@xxxxxxxxxxxxxxxxxxxxxxx
`!thread' will tell you about the stack region for a particular thread
(assuming you have enough information saved in your dump file).

By default, non-GUI threads will have around 12K of kernel stack on x86
systems, I believe. If you need to check this at runtime, there is an
`IoGetRemainingStackSize' call that you can use in kernel mode.

"Oracle" <wong.kam.keung@xxxxxxxxx> wrote in message
news:1148763290.206786.302740@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Ivan,

Is there a way that I can check the currently used stack size for that
thread in the dump file? What will be the usual size limit for a kernel
stack for a thread?

Thanks for any advice.

Ivan Brugiolo [MSFT] wrote:
My wild guess would be that you have exhausted the kernel stack
for that thread, by either creating a large on-the-stack variable,
of, by calling some _alloca() derivative function.







.

Relevant Pages

  • [Full-disclosure] PHRACK 64: ATTACKING THE CORE
    ... - The Slab Allocator ... - Slab overflow exploiting: ... - Forcing a kernel path to sleep ... - Stack Frame Flow Recovery ...
    (Full-Disclosure)
  • Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
    ... stack usages for you is that they contain a 'cpumask_t' on the stack. ... We can enable MAXSMP and raise the CPU limits some time in the future. ... not accept a specially built kernel, but only a kernel that has been ... know how extensively these distributions test and certify for many known ...
    (Linux-Kernel)
  • Re: Interrupt context...
    ... > gone through most of the posts on interrupt in usenet. ... > kernel stack and ISR is executed. ... More may be saved depending on the architecture. ... Here the kernel have assembler code to save all general ...
    (comp.os.linux.development.system)
  • Re: Why is GForth-ITC fast?
    ... The kernel and the application code (so-called "userland") do not run ... That jump entails a "stack switch", ... the only thing is I guess if you want to do syscalls ...
    (comp.lang.forth)
  • Re: Kernel stack
    ... The problem is each process does not have a TSS of its own.Only one ... in another structure.A kernel stack of size 8k ... esp entry. ... This made me believe that the stack base is the ...
    (Linux-Kernel)