To ease issue tracking in my recent projects we added resource information (short description, build number/date and a small icon) to all dlls and executables provided by us.
Formerly, we did this in a CE5.0 project and simply took over the stuff to integrate the resources also into the components of our CE6.0 BSP - never expecting that this would cause such trouble...
Unfortunately, we got an exception in GWES when the shell started up and I myself spent quite a lot time to trace down the root of the problem.
The exception occurred in the coredll function FindTypeByName (). A closer look at the function parameters and the call stack (unfortunately, most of the functions are private-private code) indicated, that there is a misinterpretation of a resource item.
K.COREDLL!FindTypeByName(unsigned long 0x00016000, unsigned long 0x00016000, const unsigned short * 0xc02b91e4)
K.COREDLL!FindType(unsigned long 0x00016000, unsigned long 0x00016000, const unsigned short * 0xc02b91e4)
K.COREDLL!DoFindResource(const info * 0x8126ab1c, const unsigned short * 0xc02b91c8, const unsigned short * 0xc02b91e4)
K.COREDLL!FindResourceW(HINSTANCE__ * 0x00400002, const unsigned short * 0xc02b91c8, const unsigned short * 0xc02b91e4)
GWES!IsForcePixelDoublingFromManifest(HINSTANCE__ * 0x00400002)
GWES!MsgQueue::NeedsPixelDoubling()
GWES!MsgQueueMgr::GetCreateMQ(unsigned long 0x00000000)
GWES!MsgQueue::SendMessageWithOptions(HWND__ * 0x0000ffff, unsigned int 0x00000219, unsigned int 0x00008000, long 0xd0a0c490, unsigned int 0x08000002)
GWES!MsgQueue::SendNotifyMessageW_I(HWND__ * 0x0000ffff, unsigned int 0x00000219, unsigned int 0x00008000, long 0xd0a0c490)
GWES!MsgQueue::SendNotifyMessageW_IW(HWND__ * 0x0000ffff, unsigned int 0x00000219, unsigned int 0x00008000, long 0xd0a0c490)
K.COREDLL!SendNotifyMessageW(HWND__ * 0x0000ffff, unsigned int 0x00000219, unsigned int 0x00008000, long 0xd0a0c490)
DEVMGR!BroadcastDeviceChange(unsigned short * 0xd0a0d078, int 0x00000001)
DEVMGR!DeviceNotifyThread(void * 0xc05056c0)
K.COREDLL!ThreadBaseFunc(unsigned long (void *)* 0xc04f7e68, void * 0xc05056c0)
Nevertheless, we did not know, in which executable the resource lookup failed. In a next step, we removed the resource information (strings and icons) from the oal.exe and – behold – this exception was never seen again :-}
10 months ago
No comments:
Post a Comment