Re: Odd call stack

Do you mean that function call across multiple processes is possible?
If it is, there are too many problems which should be addressed first,
regarding how to define and detect that kind of function call and who
will save and restore the context of 'callee process', etc. Above all,
why don't use event handling instead of 'inter-process function
calling'? Is this feature documented publicly by MS?

Michael J. Salamone wrote:
> 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+

.

Relevant Pages

  • Re: Miltu-core CPUs, threads vs AST driven approaches
    ... The way to do that is to run the several 'worker' threads at normal (not AST) level, and use the AST routines only to process I/O completion and as part of that completion move the continuation context for the relevant activity onto a 'to do' queue, which each thread visits whenever it has no processing to do. ... This preserves VMS's guarantee that no more than one AST will be active at a time, and the extremely brief processing required at AST level (compared with the processing required in each thread between interruptions) ensures that this will not impede progress even if many processors are working in parallel in the single process. ... The main gotcha here is that *all* the context for each operation must be held in that queued context structure, rather than conveniently on a thread's stack - since the thread's stack gets unwound before each such interruption. ...
    (comp.os.vms)
  • Re: interrupt routine and application pages
    ... application stack in the interrupt context. ... are still in the context of interrupted thread. ... your code runs at raised IRQL, Memory Manager just had no chance to ...
    (microsoft.public.development.device.drivers)
  • Re: Odd call stack
    ... they solved it in WinCE version 1.0. ... This is sort of a "light" context switch with no ... marshaling (just take parameters off the same stack, ... >> address space of the server process and a little magic. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Network Stack Locking
    ... :>:of continuations during IPC to avoid a full context switch. ... Even a minimal stack is ... :> continuation mechanism increases as system load increases rather ...
    (freebsd-arch)
  • Re: Odd call stack
    ... The OS migrates threads from one process context ... switch of sorts. ... >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)