Debug Zones Blues
If you develop drivers in Windows CE you should know debug zones very well.
If you don't, you should read this article on the Windows CE base team blog, and promise that you'll never ever return an error code from your driver interface functions without adding a DEBUGMSG call! This will allow other poor developers working with your driver to understand what happened in a format less cryptic than a 32 bit integer!
Using debug zones is also a great way to document what's happening inside your code, print out status changes, hardware-related events etc.
Debug zones magically disappear in release and ship builds (in release you'll keep RETAILMSG calls, that should be used only for fatal errors), can be filtered using debug zones windows inside PB or registry settings (also detailed in the linked article), and debug zones that are not enabled won't impact much on your code performances.
Most of Windows CE modules came with debug zones and enabling them could be a good way to understand what's going wrong inside a specific component.
If your module is loaded by the OS and you have to enable debug zones at runtime you can open the Target\Debug zones dialog, select your module and enable the zones that you think may provide useful information.
But what you can do if the module is loaded briefly and then immediately unloaded (a driver that cannot be initialized, for example)?
If you have source code for that module, a simple search for DBGPARAM inside the code should find the declaration of debug zones.
The first parameter of the DBGPARAM structure is the name that the module uses to register its debug zones.
Using this name to create a dword entry under HKLM\DebugZones on the device or HKEY_CURRENT_USER\Pegasus\Zones on your PC will allow you to enable zones before the module is loaded, and then read its debug output when the module is loaded/unloaded.
And what do you can do if you have only a binary module?
You can read the documentation. Everybody put his own module debug name in the doc, isn't it?
If you are not so lucky, you can still load that module yourself to access its debug information.

How can you do that?
Simply call LoadLibrary on it.
If it's a user mode DLL you can create a very simple executable that loads the module and stops there (showing a message box on an interactive device, for example). If it's a kernel mode DLL or driver you can still load it from your "dummy" application if it's not in the os image (not included with the "K" flag) and does not reference kernel-mode only APIs. If you can't load it in user mode, you can put your LoadLibrary call temporary inside the init function of another kernel mode driver.
If LoadLibrary fails you have a good int about why the module is not working. It may need some additional DLLs or some components to be added to your OS image.
Copy the module to your %_FLATRELEASEDIR% and open it using Dependency Walker.
It will show any missing DLL and any entry point that is expected by your module inside one of the existing DLLs.
If LoadLibrary succeeded, your module is loaded and you can see it and its debug zones inside the debug zones window, but this window does not show the module's debug name (that may be a suggestion for the PB development team...).
To find it
you should use the Target Control window.
Inside the debug shell you can use the:
gi mod
command to list all loaded modules. Each module has a module id (number).
You can find the id of your module and then use the
zo M <id>
command to display its information.
Now you have your module name and you can create your registry keys and find what's wrong with that driver.
posted on Wednesday, February 4, 2009 2:00 PM Print
No comments posted yet.

Post Comment

Title *
Name *
Comment *  
Toradex logo

Cookies in Use
Tag Cloud