Patch for Entrek TOOLBOX Windows CE Edition

Overview

Installation

Issues Corrected by this Patch

Known Issues

Feedback

Overview

This patch corrects several issues in Entrek TOOLBOX Windows CE Edition Version 1.4.

 

Files to patch both Standard and Professional Editions are available.  Download the proper patch for your Entrek TOOLBOX.

 

This patch contains fixes for several important issues in Entrek CodeSnitch.

 

For Professional Edition, get the Professional Patch.

 

For the Standard Edition, get the Standard Patch.

Installation

This patch is for Entrek TOOLBOX Windows CE Edition Version 1.4.  Please do not install this patch for any other version of Entrek TOOLBOX.  It will not work.  If you need to upgrade your installation to version 1.4, please visit www.entrek.com/upgrade_request.htm.

 

Installations steps:

 

  1. Close any running instance of Entrek ProcMan or Entrek CodeSnitch.
  2. Unzip the included files to your Entrek TOOLBOX installation path.  For example, C:\Program Files\Entrek\TOOLBOX\\Patch14.
  3. Make a backup of the files in the TOOLBOX installation directory.  This is typically C:\Program Files\Entrek\TOOLBOX.  For example, make a backup in C:\Program Files\Entrek\TOOLBOX\ Backup14.
  4. Now copy the unzipped files to the TOOLBOX installation directory.  For example, copy from C:\Program Files\Entrek\TOOLBOX\Patch14 to C:\Program Files\Entrek\TOOLBOX.  NOTE: Do not first delete the files under Entrek\TOOLBOX.  This patch does not contain all files needed to use the product.  It only have files that have been updated.
  5. You may need to reset your target device.

 

The next time you connect CodeSnitch to your target device, it will install and use the new files.

Issues corrected by this patch

This patch corrects the following issues.  If you are not experiencing any of these problems, there is no need to install this patch.

 

  1. Debug helper file (dbghelp.dll) has been updated with the latest redistributable from Microsoft.  This file is compatible with Windows CE 5.0 and VS 2005.

  2. Problems with LocalAlloc and HeapAlloc.

 

a)      Calls to LocalAlloc and HeapAlloc not tracked

b)      Memory leaked because of failure to call LocalFree or HeapFree not reported

c)       False "Invalid Signature" errors when calling LocalFree or HeapFree

 

These issues occur on Windows CE versions 4.2 and higher.

 

For debug builds of your application, calls to LocalAlloc and HeapAlloc are #define'd to be LocalAllocTrace and HeapAllocTrace respectively (see winbase.h).  CodeSnitch did not hook these APIs, and thus no tracking/reporting was performed when these APIs were called.  Further, when calling LocalFree or HeapFree to free the memory, CodeSnitch reported an “Invalid Signature” error if the “Detect heap overwrites” option was turned on.

 

CodeSnitch now tracks calls to LocalAllocTrace and HeapAllocTrace.

 

  1. CodeSnitch can hang when instrumenting

 

On some devices based on Windows CE version 4.0 and higher, CodeSnitch would hang when instrumenting binaries.

 

  1. No symbols found

 

On some devices, especially Windows CE version 4.0 and higher, no address or stack trace information was reported.  Thus no symbolic information or source code was displayed for any event.

 

  1. Code Signing

 

This is primarily for Smartphone developers.

 

CodeSnitch makes a slight modification to binaries that it instruments.  This modification invalidates any signature the binaries may have been signed with.  These binaries would then fail to load and thus could not be tested with CodeSnitch.  The workaround for this issue was to not sign your binaries when testing with CodeSnitch.

 

This is still an issue with this patch.  You must continue to not have binaries signed when running under CodeSnitch.

 

This works fine for binaries that do not need to be signed with a privileged certificate.  However, some binaries must be signed with a privileged certificate for various reasons.  These binaries could not then be tested with CodeSnitch at all.

 

With this patch, a new workaround for testing priviledged binaries is available.  There are some manual steps involved, but it will work.  These are the steps:

 

1.       Build and deploy your application and DLLs as you would normally.

2.       Use CodeSnitch to instrument the binaries, but do not run.  That is, use the "Instrument Only" option.  Do not disconnect CodeSnitch.  Doing so will uninstrument the binaries.

3.       Use an ActiveSync Explorer window or the Remote File Viewer to copy all instrumented binaries to a folder on your development workstation.  Also copy the files generated by CodeSnitch.  These are of the form $coredll.00, $ole32.00, etc. and can be found in the \Windows directory of the target device.

4.       Use the signcode.exe tool to sign the instrumented binaries, as well as the CodeSnitch-generated files.  Sign all modules with the same privileged certificate you would normally sign them with.

5.       Copy all the signed binaries back to their original locations on the target device.

6.       Start your program as you would normally.  With CodeSnitch connected, you will be able to track events in your application.

 

With previous versions of CodeSnitch, it was not possible to manually sign the CodeSnitch-generated files.  All other binaries could be signed using the steps outlined above, but since the CodeSnitch-generated files could not be signed, the whole application would fail to load.  The CodeSnitch-generated files can now be successfully signed.

 

You will need to repeat the steps above each time you make a change to your application that you want to test with CodeSnitch.

 

Also, normally CodeSnitch will uninstrument binaries when it is disconnected.  However, uninstrumentation will fail once the binaries are signed.  The only way to uninstrument is to redeploy your binaries, copying over the binaries that were tested with CodeSnitch.  Doing this orphans the CodeSnitch-generated files, so those files will need to be manually deleted.

Known Issues

 

  1. Tools will not work with against Smartphone 2002 and Smartphone 2003 devices.

 

Entrek TOOLBOX will work with Smartphone.  You must, however, follow a few simple instructions before connecting to your target device, whether it is a physical device or the Smartphone emulator.

 

First, your target device must be unlocked for development.  Effectively, this means that you must be able to provision the device with certificates that you generally sign your application with.  Before loading an application or a DLL, the operating system will verify that the application is signed with a valid certificate and assign a trust level to the application, depending if the certificate is installed in the "Privileged Certificate Store" or the "Unprivileged Certificate Store".

 

Unlocked phones can also run unsigned applications.  Unsigned applications will run, but in unprivileged mode.

 

ProcMan uses privileged operating system functions.  For it to be able to run, then, the binary files ProcMan installs on the target device must first be signed with a certificate which is installed in the "Privileged Certificate Store".  You must manually sign these files before connecting ProcMan.

CodeSnitch does not use privileged operating system functions, but it (APICore.DLL) does get loaded into the address space of the process being tested.  If the application is unprivileged, this is fine.  However, if running a privileged process, APICore.DLL will fail to load unless it is signed with a privileged certificate.

We recommend signing all Entrek TOOLBOX binaries with a privileged certificate.  Follow these steps:

 

1.       Use the signcode.exe tool included in the Smartphone SDK to sign all Entrek TOOLBOX binaries.  For Smartphone 2002, signcode.exe can be found in \Windows CE Tools\wce300\Smartphone 2002\Tools.  For Smartphone 2003, it can be found in \Program Files\Windows CE Tools\wce420\SMARTPHONE 2003\Tools.  The Entrek TOOLBOX binaries can be found in \Program Files\Entrek\TOOLBOX\Target.  From there, go to wce300\ARM for Smartphone 2002 and wce400\ARMV4 for Smartphone 2003.

2.       For CodeSnitch, you must sign toolbox.exe, tbhelp.dll, OnlineManager.DLL, APICore.DLL, and storemance.dll.

3.       For ProcMan, you must sign toolbox.exe, tbhelp.dll, procmance.dll, and storemance.dll.

4.       Make sure your target device is properly provisioned with the certificate used to sign the binaries.

5.       Connect CodeSnitch or ProcMan to your target device.  This will install all the newly signed binaries to the target.

 

For more information about Smartphone security, certificates, and other signing issues, please refer to the information provided in your Smartphone SDK.

 

  1. When connecting, ProcMan and CodeSnitch install the wrong binaries on the target device.

 

This issue can occur when targeting Windows CE versions 4.0 and higher that have an ARM-based processor, including XScale and TI OMAP.  Entrek TOOLBOX ships with binaries built for ARMV4, ARMV4I, and ARMV4T.  When connecting, for example, it may install ARMV4 binaries, though the target device is ARMV4I.

 

There is a workaround for this issue.  Both ProcMan and CodeSnitch accept a command line parameter called “targetcpu”.  You can specify this parameter directly, or create a shortcut that contains it.  Note that if you target two different CPUs (for example, ARMV4I and X86), you will need a shortcut for each target.  The command line parameter must be specified as /targetcpu:<cpu_dir> where <cpu_dir> is the name of the directory that contains the binaries you want the tool to use.  Examples are /targetcpu:ARMV4, /targetcpu:ARMV4, and /targetcpu:ARMV4T.

Feedback

Please contact Entrek Support by email at support@entrek.com, or by phone at

+1 (425) 497-1662.

 

Copyright © 2006 Entrek Software, Inc.