faq.htm

evc WinCE+内存检测工具补丁evc WinCE+内存检测工具补丁evc WinCE+内存检测工具补丁

<li>Select your project in the list, and pick the configuration in the combo box above it.
<li>Select the C/C++ tab.
<li>Select the "General" category, and make sure the combobox under Debug Info has Program database selected.
<li>For Static library projects, that's it. You still need to update your main DLL or EXE application, though.
<li>For the DLL or EXE projects, click the Link tab.
<li>In the "General" category, check the box labelled "Generate debug info".
<li>Select the "Customize" category, and check the box labelled "Use Program Database". Change the default PDB file if you wish.
<li>You're done. Save your project, rebuild, and try again.
</ol>
				<h5><a href="#top">Back to Top</a></h5>
				<P>&nbsp;</P>
<hr><a name="10"><b>Product: CodeSnitch</b></a><h4>How do I get CodeSnitch to automatically scroll to the most recently added event?</h4>You can get what you want a different way:<br>
<br>
Do the following:<br>
<br>
<ul>
<li>Select View | Preferences
<li>Select the Columns Tab
<li>Check the 'Sequence' column, then click OK.
<li>Return to the Event Viewer (the main window where the events are)
<li>Click the 'Sequence' column header twice, or until you see the down arrow (v). This sorts the events in descending order according to that column.
</ul>
Now, as new events are added, they will appear at the top of the events instead of the bottom.<br>
<br>
This also works with any of the other fields. If you sort by a field, when new events are added, the sort order is maintained.<br>
				<h5><a href="#top">Back to Top</a></h5>
				<P>&nbsp;</P>
<hr><a name="14"><b>Product: CodeSnitch</b></a><h4>Can CodeSnitch connect to a device without RAM file system support?</h4>No. CodeSnitch can connect to a MinKern configuration, but the fsysram module must be<br>
included as part of the platform because it uses some file system APIs in order to instrument<br>
modules and transfer information.<br>
<br>
Of course, if you have no RAM file system, there are no modules that CodeSnitch would be able to instrument anyway.<br>
				<h5><a href="#top">Back to Top</a></h5>
				<P>&nbsp;</P>
<hr><a name="16"><b>Product: CodeSnitch</b></a><h4>Can CodeSnitch report false positives for memory and resource leaks?</h4>Yes. If you use APIs not supported by CodeSnitch to free memory allocated by APIs that are supported by CodeSnitch, a false memory leak will be reported. Here are some APIs that can cause this:<br>
<br>
VariantClear (for vt equal to VT_ARRAY)<br>
SafeArrayDestroy (for vt equal to VT_BSTR)<br>
ReleaseStgMedium (for storage type equal to TYMED_HGLOBAL)<br>
<br>
				<h5><a href="#top">Back to Top</a></h5>
				<P>&nbsp;</P>
<hr><a name="17"><b>Product: CodeSnitch</b></a><h4>I am getting what appears to be a false memory underwrite/overwrite error.</h4>If you get a memory underwrite or overwrite error, but you are certain that no such error is actually occurring, you probably have a mixed instrumentation problem. That is, memory was allocated with an unsupported API and deallocated with a supported API, or vice-versa. The online help lists all APIs that are supported by CodeSnitch. In this case, usually the best thing to do is turn off 'detect memory underwrites and overwrites', because CodeSnitch may be corrupting the heap when a LocalFree is called. Here are some APIs to watch out for:<br>
<br>
CeReadRecordProps (may perform a LocalAlloc)<br>
GetClipboardDataAlloc (may perform a LocalAlloc)<br>
<br>
These problems will go away as we release new API support for CodeSnitch.<br>
				<h5><a href="#top">Back to Top</a></h5>
				<P>&nbsp;</P>
<hr><a name="18"><b>Product: CodeSnitch</b></a><h4>Why doesn't CodeSnitch track new/delete in an MFC application?</h4>This was fixed in our next service release on February 6, 2002.<br>
<br>
You can use the following workaround to force your application to link with coredll before MFC, which will make your application use coredll's implementation of new and delete instead of MFC's:<br>
<br>
The workaround requires you to modify the project build settings.<br>
<br>
<ol>
<li>Open your project in eMbedded Visual C++.
<li>Click the "Project\Settings..." menu item.
<li>Click the "Link" tab.
<li>Select "Input" from the "Category" dropdown combobox.
<li>Add the following list of libraries to the "Object/library modules" edit box.
<ul>
<li>coredll.lib
<li>corelibc.lib
<li>mfcs42.lib
<li>mfcce300.lib
<li>olece300.lib
<li>ole32.lib
<li>oleaut32.lib
</ul>

<li>Check the "Ignore all default libraries" checkbox.
<li>Cleanly rebuild your application or module.
</ol>
NOTES:<br>
a) "coredll.lib" MUST precede "mfcce300.lib".<br>
b) For Pocket PC applications, you will need to add "aygshell.lib" to the list.<br>
c) Other default libraries may be required depending on your platform.<br>
d) Be sure to include other project-specific libraries.  The list above *adds* to (not replaces) the list of libraries already being linked to.<br>
<br>
				<h5><a href="#top">Back to Top</a></h5>
				<P>&nbsp;</P>
<hr><a name="22"><b>Product: CodeSnitch</b></a><h4>CodeSnitch hangs if I select File | Save or File | Open</h4>A fix for this problem was provided in the February 6, 2002 service release of CodeSnitch.<br>
<br>
For some installations of CodeSnitch, the program hangs when File | Save or File | Open is selected. This has been found to only occur on Windows 2000 with Internet Explorer version 6. If you have a different configuration than the above and you experience this problem, please submit a bug report or email [e-mail].<br>
<br>
				<h5><a href="#top">Back to Top</a></h5>
				<P>&nbsp;</P>
<hr><a name="24"><b>Product: CodeSnitch</b></a><h4>Why don't I see an overwrite in my test code which intentionally overwrites memory?</h4>Many people have tried this test or something like it:<br>
<br>
char buf[3];<br>
strcpy(buf, "Hello");<br>
<br>
and have noted that no memory overwrite is detected,<br>
though one is obviously present. The reason for this<br>
is that CodeSnitch does not detect overwrites in<br>
stack memory, only heap memory.<br>
<br>
Secondly, CodeSnitch detects the overwrite at the time the<br>
memory is freed, not at the moment it occurs. Example:<br>
<br>
char *str = new char[3];<br>
strcpy(str, "Hello");<br>
free(str);  // <-- error not reported until this line<br>
<br>
The same applies to underwrites. This has to do with the way<br>
CodeSnitch tracks the error: It intercepts the API call to allocate<br>
memory, inserts fill bytes before and after the memory and returns<br>
the modified memory block to the user. When the block is freed,<br>
CodeSnitch checks the filled areas to see if it has changed. If it<br>
has, it reports an underwrite or overwrite.<br>
				<h5><a href="#top">Back to Top</a></h5>
				<P>&nbsp;</P>
<hr><a name="26"><b>Product: CodeSnitch</b></a><h4>I see Function() in [Unknown file], line 0 in the callstack pane</h4>This happens if CodeSnitch found or the user specified symbols<br>
that do not match the current event. You can usually fix the problem by clearing<br>
the symbol path and ensuring only the correct symbols are selected for an event.<br>
<br>
To do this:<br>
<br>
<ol>
<li>After gathering events, save your event log using File | Save.
<li>Close the event log.
<li>Go to View | Preferences, and select the 'Clear' button in the 'Settings' tab, then click OK.
<li>Return to the main screen, and open your saved event Log.
<li>When CodeSnitch needs to display a location, the Find File dialog will appear, requesting you to enter the location of the DLL that contains the symbols needed to resolve the location.
<li>When entering a DLL location, pay attention to the message displayed in the bottom of the Find File dialog. If the currently selected folder has a file with the right name but CodeSnitch says it is the wrong one, selecting it may cause the [Unknown file] problem.
<li>You may re-resolve symbols for an item in the callstack or event log at any time by right-clicking and selecting 'Locate Symbols' to bring up the Find File dialog again.
</ol>
				<h5><a href="#top">Back to Top</a></h5>
				<P>&nbsp;</P>
<hr><a name="28"><b>Product: CodeSnitch</b></a><h4>I'm trying to run an application in the x86em emulator under CodeSnitch but when I run it the application doesn't start.</h4>One or more redirector files (like $COREDLL.00) may be referenced by an instrumented application but are missing.<br>
<br>
You can repair this condition by selecting 'Dependencies' for your application and unchecking ALL of the boxes that are not grayed, then clicking Go! and running the application. Then, close the application and try again. This time you should receive some events.<br>
<br>
If this doesn't work, it is possible some old files are left behind from version 1.1 and lower ($000000.DLL, etc). Deleting the files will not do any good; you must redeploy any instrumented applications and modules in the emulator directory. To identify an instrumented application, run<br>
the following command, assuming you have installed eMVT 3.0:<br>
<br>
depends /imports *.dll > output.log<br>
depends /imports *.exe > output2.log<br>
<br>
Next, open the output.log and output2.log in Notepad, and search for the strings $CORE and $0000.  If you find any occurrences of these files, you will need to redeploy the DLL or EXE that refers to it.<br>
				<h5><a href="#top">Back to Top</a></h5>
				<P>&nbsp;</P>
<hr><a name="30"><b>Product: CodeSnitch</b></a><h4>CodeSnitch is not responding for a long time when viewiing event logs in Windows XP.</h4>There are some issues with the DBGHELP API supplied by Microsoft that requires CodeSnitch to contain code which works around these issues. On Windows ME, NT, and 2000, the workaround is fast and unnoticeable. On Windows XP, the DBGHelp API that comes with the OS seems to behave differently, causing the workaround to be many times slower. We are still researching this issue to determine if this is a bug in our code or a bug in Windows XP. However, there is a workaround:<br>
<br>
If you use the old DBGHELP.DLL that ships with Windows 2000 or a certain older version of the Microsoft Platform SDK, this problem disappears. However, since it may introduce other problems still unknown as of yet, we feel it necessary to withhold the file from the TOOLBOX installer until we have determined it is safe to include it.<br>
<br>
You can download the old DBGHELP.DLL from our FTP site at ftp://ftp.entrek.com/Unsupported/DBGHelp.dll .<br>
DO NOT copy it into your system folder!  Copy it directly into the C:\Program Files\Entrek\TOOLBOX\Bin directory.<br>
				<h5><a href="#top">Back to Top</a></h5>
				<P>&nbsp;</P>
<hr><a name="34"><b>Product: CodeSnitch</b></a><h4>My application runs very slowly under CodeSnitch.  Is there any way to get better performance?</h4>CodeSnitch does send many events to the desktop, at least one for each API call it traps.  In some cases, this may cause the application to run very slowly when running under CodeSnitch.<br>
<br>
Here are a few ways to get better performance:<br>