Re: Odd call stack

From: "Michael J. Salamone" <mikesa#at#entrek#dot#com>
Date: Sun, 1 May 2005 21:23:59 -0700

Perfectly normal in WinCE. The OS migrates threads from one process context
to another when calling system services. The migration is a light context
switch of sorts. Same thread, same stack, same registers - just maps in the
address space of the server process and a little magic.

--
Michael Salamone [eMVP]
Entrek Software, Inc.
www.entrek.com

"Thomas" <totohero@xxxxxxxxx> wrote in message
news:ac9276f6.0505011830.28f41fc2@xxxxxxxxxxxxxxxxxxxxx
>I was debugging my own audio device driver and get follwoing call
> stack log after stopped at some breakpoint inside the driver code.
>
> You can see NK and DEVICE in the middle of the call stack. Does that
> mean the functions of an EXE file can be called by another
> executables? It's impossible AFAIK. Some one please explain this for
> me?
>
>
>
> Call Stack: cprog.exe: 0x59DEC862 17:15:27 05/01/2005 +9+
> WAVEDEV!HandleWaveMessage(MMDRV_MESSAGE_PARAMS * 0x2403e768,
> unsigned long * 0x2403e760) line 559
> WAVEDEV!WAV_IOControl(unsigned long 0x0000003a, unsigned long
> 0x00000000, unsigned char * 0x00000057, unsigned long 0x00410057,
> unsigned char * 0x005f0056, unsigned long 0x004f0049, unsigned long *
> 0x006f0043) line 936 + 12 bytes
> WOWXT_ARM_WCE_PPC_DRIVER!011e3624()
> WOWXT_ARM_WCE_PPC_DRIVER!011e2a80()
> DEVICE!FS_DevDeviceIoControl(fsopendev_t * 0x00000000, unsigned
> long 0x000005c8, void * 0x00000001, unsigned long 0x0000040b, void *
> 0x00000004, unsigned long 0x2403e764, unsigned long * 0x00045d10,
> _OVERLAPPED * 0x00000000) line 1252 + 44 bytes
> NK!SC_DeviceIoControl(void * 0x00000000, unsigned long 0x000005c8,
> void * 0x00000001, unsigned long 0x0000040b, void * 0x00000000,
> unsigned long 0x2403e814, unsigned long * 0x2403e844, _OVERLAPPED *
> 0x00000000) line 3658 + 64 bytes
> COREDLL!xxx_DeviceIoControl(void * 0x00000000, unsigned long
> 0x000005c8, void * 0x00000001, unsigned long 0x0000040b, void *
> 0x2403e760, unsigned long 0x00000004, unsigned long * 0x2403e764,
> _OVERLAPPED * 0x00000000) line 27 + 92 bytes
> AUDEVMAN!CAudioDevice::wavMessage(CAudioDevice * const 0x00000000,
> unsigned int 0x000005c8, unsigned long 0x00000001, unsigned long
> 0x0000040b, unsigned long 0x00000000) line 846 + 56 bytes
> End Call Stack: cprog.exe: 0x59DEC862 17:15:27 05/01/2005 +9+

.

Follow-Ups:
- Re: Odd call stack
  - From: Thomas

References:
- Odd call stack
  - From: Thomas

Prev by Date: Odd call stack
Next by Date: Re: Why is there marvellous mistake in the process WinCE starting
Previous by thread: Odd call stack
Next by thread: Re: Odd call stack
Index(es):
- Date
- Thread

Relevant Pages

Re: Odd call stack
... will save and restore the context of 'callee process', ... > Michael Salamone ... >>I was debugging my own audio device driver and get follwoing call ... >> stack log after stopped at some breakpoint inside the driver code. ...
(microsoft.public.windowsce.platbuilder)
[PATCH 14/17] uml: fix big stack user
... Switch this proc from storing 4k of data on the stack to keeping ... it on the heap. ... Maybe it's not called in process context but only in early boot context (where ... in UML you have a normal process stack on the host) but just to be safe, ...
(Linux-Kernel)
Re: 4k stacks in 2.6
... > at the bottom of the stack and is referenced by masking bits off %esp. ... > So the stack size must be constant whether in process context or IRQ ... send the line "unsubscribe linux-kernel" in ...
(Linux-Kernel)