Compartilhar via


Thread names and CeLog

Posted by: Sue Loh

[Back from MEDC-Europe and I had a great time! It was nice to talk to our European customers and fun to meet some people in person who I'd only previously "met" online. I liked Nice too, though as someone who's used to Atlanta now (hot and humid) it was a tad bit chilly.]

Today someone asked me how to get a thread's name from its ID / handle.  I think they were actually asking in regard to CeLog or Remote Kernel Tracker, but here is the general answer.

Windows CE records the thread start address (the function that was passed to CreateThread()) when a thread is created.  It stores the start address in the thread structure inside the kernel, but there is no API for you to query the start address at run time.  The only way the start address is exposed to you is in the CeLog (Remote Kernel Tracker) data stream.  When we log a "thread create" event in the log, we also log the start address of the thread.  So, you could find the start address by looking at the .clg file using the "readlog" command-line tool.

If you can rebuild the image, then turning on the IMGPROFILER environment variable will help thread naming.  This is the setting which enables the kernel profiler and adds profiling symbols to the image.  It helps CeLog because, if the profiling symbols are built into ROM, then when CeLog logs the "thread create" events it will take the start address and use the symbols to look up the thread name, and add this to the log.  So, even though CeLog is not really related to the profiler, it can take advantage of the presence of the profiler to add thread names to the log.

The "readlog" command-line tool can also look up thread names by taking the thread start addresses from the .clg file and looking up the symbols using the .map files in your release directory.  If you run "readlog -v" on the log it will try to look up symbols using .map files from the release directory, and print them as it dumps the log file.  Even better, if you run "readlog -fixthreads" on the log, it will take the old log, add the symbols to it, and spit out a new log file with the symbols built in.  Then you can open the new log and see the names in Kernel Tracker.  So you don't actually have to modify the image to get the thread names.  You can take the .clg file and look up symbols after the fact, as long as you have all the .map files you need.

Here's the one problem with that answer though: it's more usable by OEMs than application developers.  Application developers don't have an easy way to get a copy of the readlog tool.  I thought for a long time that it was part of our SDK, but it turns out that I was mistaken, and that there is no easy way to add it to the SDK.  They could download an evaluation edition of Platform Builder to get a copy of readlog.  Application developers also only have .map files for their own modules.  They can't look up names for system threads because they don't have symbols to look them up.