Interpreting ERROR!!! Calling xxx_SetProcPermissions in Wince 6.0 with platman 'cepermon' tool

I'm working on an SoC architecture where various drivers and user
application code need to share access to the specialized hardware
coherently. For example, the state video subsystem must be identically
viewed by all clients - display drivers, dshow filters, etc.

To implement this, I wrapped the hardware libraries in a device driver,
using IOCTLs to marshall bits in from user mode. Works like a champ.

However, now when I run the Remote Performance Monitor tool, I get a fairly
rich spew of messages out the debug port when using the driver.
137392 PID:4cc0002 TID:5310002 ERROR!!! Calling xxx_SetProcPermissions
137696 PID:4cc0002 TID:5310002 ERROR!!! Calling xxx_SetProcPermissions
138404 PID:4cc0002 TID:5310002 ERROR!!! Calling xxx_SetProcPermissions
138707 PID:4cc0002 TID:5310002 ERROR!!! Calling xxx_SetProcPermissions
139414 PID:4cc0002 TID:5310002 ERROR!!! Calling xxx_SetProcPermissions
139780 PID:4cc0002 TID:5310002 ERROR!!! Calling xxx_SetProcPermissions
140424 PID:4cc0002 TID:5310002 ERROR!!! Calling xxx_SetProcPermissions
140828 PID:4cc0002 TID:5310002 ERROR!!! Calling xxx_SetProcPermissions
141435 PID:4cc0002 TID:5310002 ERROR!!! Calling xxx_SetProcPermissions
or roughly every 300 msec while viewing any one of a number of parameters
including CE processor Statistics/% processor time

This is on a build where only the display driver is accessing the hardware
device driver. Altering the build so that the display drier is linked to a
KM DLL exporting the APIs directly, the messages go away.

Anyone have a clue what the origin/interpretation of this message is?

--Richard R. Lee eMVP

Steve
Sun Nov 26 09:54:54 CST 2006

>141435 PID:4cc0002 TID:5310002 ERROR!!! Calling xxx_SetProcPermissions
That message means the application is calling SetProcPermissions, which is
deprecated in V6.0. In other words the app was not ported to V6.0. The
SetProcPermissions call is ignored except for printing that message. Are you
CERTAIN it's the V6.0 version of the application you are running?

>This is on a build where only the display driver is accessing the hardware
>device driver. Altering the build so that the display drier is linked to a
>KM DLL exporting the APIs directly, the messages go away.
I'm not quite following what you are saying on that...



--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com

Sue
Tue Nov 28 11:03:17 CST 2006

Richard, could you set a breakpoint on
{,,k.coredll.dll}xxx_SetProcPermissions and on
{,,coredll.dll}xxx_SetProcPermissions and catch the callstack where this is
happening? That'd be the easiest way to debug. If it's something in Remote
Performance Monitor I'll report it. It's possible that RPM is using CE5
device side bits or something, though if it needed to call
SetProcPermissions in 5.0 I doubt the CE5 bits would "just work" in CE6.

Sue
sloh@microsoft.com (remove "online" from reply-to address)
http://blogs.msdn.com/ce_base/
_____________________________________________________________
This posting is provided "AS IS" with no warranties, and confers no rights.
_____________________________________________________________

Richard
Tue Nov 28 21:30:14 CST 2006

Let's start by killing all the lawyers. Leaving
c:\ymzki\private\winceos\coreos\core\thunks out of the private code
distribution will continue to be a source of pain. Nic S - are you
listening?

This is from a MIPSII_FP build. My initial post was based on behavior on a
MIPSIV_FP.
Setting the breakpoint on the entry to xxx_SetProcPermissions() was
unmanagable. Everything comes through there, and that goes double in KM.

On this platform I do not even need to have my magic device driver loaded.
The
'ERROR!!! Calling xxx_SetProcPermissions' message is emitted once an start
up of Perfmon, and repeatedly when 'Add to Chart' is brought up.
{xxx_SetProcPermissions(unsigned long),tkfuncs.cpp,COREDLL.DLL,,} 0x40048C58

xxx_SetProcPermissions:
40048C44 addiu sp,sp,0xFFD8
40048C48 sw ra,0x20(sp)
$M21039:
40048C4C sw a0,perms
40048C50 lui t0,0x4001
40048C54 addiu a0,t0,0x733C
40048C58 jal NKDbgPrintfW (4004c508) <<< BP here, the call to
print the msg
40048C5C nop
40048C60 addiu a0,zero,1
40048C64 sw a0,0x14(sp)
40048C68 b $M21039+28h (40048c74)
40048C6C nop

Here's one on start up of Perfmon
COREDLL!xxx_SetProcPermissions(unsigned long 0x00000000) line 170 + 8 bytes
RTSCE!CSession::IsCloseRequested(unsigned char * 0x00000001, unsigned long
0x4006c64c) line 660

And later here:
COREDLL!xxx_SetProcPermissions(unsigned long 0x0000ffff) line 170 + 8 bytes
CEPERFMON!CBatteryPerf::QueryInterface(const _GUID & {...}, void * *
0x00000010) line 221 + 20 bytes

and here:
COREDLL!xxx_SetProcPermissions(unsigned long 0x00000000) line 170 + 8 bytes
CEPERFMON!CSystemPerf::GetSystemSnapshot(_SYSTEMTIME * 0x1882fca8,
_SYSTEMTIME * 0x1882fc90, _CE_SYSTEM_INFO * 0x1882fc98, _LARGE_INTEGER *
0x00000000, _LARGE_INTEGER * 0x00000000, _CEPERFMON_PROCESS_DATA * *
0x00000000, _CEPERFMON_THREAD_DATA * * 0x00000000, _CEPERFMON_HEAPLIST_DATA
* * 0x00000000, _CEPERFMON_HEAP_DATA * * 0x00000000) line 186 + 8 bytes


Happy hunting!

--
-Richard Lee eMVP

Dean
Wed Nov 29 11:50:04 CST 2006

> Let's start by killing all the lawyers. Leaving
> c:\ymzki\private\winceos\coreos\core\thunks out of the private code
> distribution will continue to be a source of pain. Nic S - are you
> listening?

Agreed. It's not even in the premium source (in CE5, anyway), a decision I
can't even begin to understand.

--
Dean Ramsier - eMVP
BSQUARE Corporation

Steve
Wed Nov 29 12:09:42 CST 2006

>> Let's start by killing all the lawyers. Leaving
>> c:\ymzki\private\winceos\coreos\core\thunks out of the private code
>> distribution will continue to be a source of pain. Nic S - are you
>> listening?

>Agreed. It's not even in the premium source (in CE5, anyway), a decision I
>can't even begin to understand.

Yes, that's most annoying. As it confuses people on the debug process.
Although even with the source I don't think it would matter on that point
since it's all going to be in Assembly code and none of the assemblers
generate debug symbols for file and line information :( A point that is
significantly more painful in my book!

--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com

Sue
Wed Nov 29 12:49:11 CST 2006

FYI - The other day I logged a bug report requesting for the thunks
directory to be added to our shared source. I don't know why it was omitted
either.

Sue
sloh@microsoft.com (remove "online" from reply-to address)
http://blogs.msdn.com/ce_base/
_____________________________________________________________
This posting is provided "AS IS" with no warranties, and confers no rights.
_____________________________________________________________

Dean
Wed Nov 29 14:46:28 CST 2006

Thanks Sue!

--
Dean Ramsier - eMVP
BSQUARE Corporation


"Sue Loh [MS]" <sloh@online.microsoft.com> wrote in message
news:OME2Rc%23EHHA.2112@TK2MSFTNGP03.phx.gbl...
> FYI - The other day I logged a bug report requesting for the thunks
> directory to be added to our shared source. I don't know why it was
> omitted either.
>
> Sue
> sloh@microsoft.com (remove "online" from reply-to address)
> http://blogs.msdn.com/ce_base/
> _____________________________________________________________
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> _____________________________________________________________
>
>