This information will be included on MSDN soon...
How to: Create Log Files
You can create log files with diagnostic information about interoperability, loading the application, and networking. You can enable logging by setting the registry keys.
By default, log files are written to the same directory containing the application being diagnosed. However, you can you can specify a path and other options with registry keys as follows:
A log file has the following parts: "netcf_" + (Application name) + (component) + (Process ID) + ".log".[component] corresponds to the type of logging information, either Interop, Loader, or Network. [Application name] is optional and [process ID] are optional and are specified with registry settings.
For example, a Loader log file for "MyApp.exe" with the application name and process ID would be: netcf_MyApp_Loader_2066923010.log
To enable logging: Set the Enabled key value 1: HKLM\Software\Microsoft\.NETCompactFramework\Diagnostics\Logging\Enabled This key value must be set to enable the three types of logging: Interop, Loader, and Networking. Note that the sub keys under Logging do not exist by default. You can turn off all logging by setting this value to zero.
To specify a path for the log file (optional): Set the Path key value to a string: HKLM\Security\.NETCompactFramework\Diagnostics\Logging\Path This key is only accessible by applications that can write to the secure registry. If a path is not specified, the log file is written to the same directory containing the application.
To include the application in the name (optional): Set the UseApp key value to 1: HKLM\Software\Microsoft\.NETCompactFramework\Diagnostics\Logging\UseApp This key is useful if you want to run multiple applications and get separate log files. If there are two applications writing log files to the same directory, the older log file will always get overwritten with the newer log file when the second application is run. This key can be used as a differentiator for the log file.
To include the process ID in the name (optional): Set the UsePid key value to 1: HKLM\Software\Microsoft\.NETCompactFramework\Diagnostics\Logging\UsePid This key is useful if you want to run the same application but have separate logs. This adds the process ID to the log file name, so that each run of the same application creates a new log file with a different name.
To log events as they occur (optional): Set the Flush key value to 1: HKLM\Software\Microsoft\.NETCompactFramework\Diagnostics\Logging\Flush This value causes the common language runtime to write log events to the log file as they occur instead of keeping them in the buffer and writing then when the buffer is full. Flushing negatively affects performance of the application and might modify timing of the application slightly since every piece of logging information is written out immediately, but it can be useful to diagnose problems related to application crashes or other errors where you might want to get the last few logs that resulted in the crash. If this key is not present or not set, then the default operation is to not flush.
To enable Interop logging: Set the Enabled key value to 1: HKLM\Software\Microsoft\.NETCompactFramework\Diagnostics\Logging\Interop\Enabled
To enable Loader logging: Set Enabled value to 1 to enable Loader logging, or set to 2 to enable Loader and GAC related logging: HKLM\Software\Microsoft\.NETCompactFramework\Diagnostics\Logging\Loader\Enabled
To enable Networking logging: Set the Enabled value to 1: HKLM\Software\Microsoft\.NETCompactFramework\Diagnostics\Logging\Networking\Enabled The networking log file is binary and cannot be read without the viewer, which is not currently available.
Interop Log Files
The output for interop logging consists of the signatures of interop function calls as they occur at run time, as well as any error messages.
The signatures for both managed-to-native and native-to-managed calls are logged, and include the following types of calls:
These function signatures can help you troubleshoot problems when calling or returning from an interop function call, such as when a parameter is not initialized as expected or when the program terminates unexpectedly.
The output for a function signature entry consists of three lines for each interop call:
Line 1) The first line represents flags identifying the type of function call made, and has one or more of the following elements:
[pinvokeimpl] - A managed-to-native call that uses the System.Runtime.InteropServices.DllImportAttribute attribute. [Ctor] - A constructor for an interop assembly class, generated by the Type Library Importer (Tlbimp.exe). [preservesig] - The managed and native functions are assumed to have the same signature, with no translation from HRESULT to exception enforced by the runtime. [delegate] - Indicates that the function is a native-to-managed delegate callback. The delegate acts as a function pointer in native code.
Line 2) The second line of the interop log file represents the managed signature. For managed-to-native function calls, this line identifies the managed function that describes the PInvoke or com interface method. For native-to-managed function calls, this line identifies the managed function that is being called from native code.
Line 3) The third line represents the native signature, as expected by the runtime. This line identifies data types for each parameter and provides information about how the managed object data is marshaled. The runtime assumes the correct types are specified by the System.Runtime.InteropServices.DllImportAttribute or in the COM interface signature definition. Failure to specify the correct types is a common error that can result in unexpected behavior because the function called is executed with incorrect parameter values. Every type has a default marshaling type. Note that the marshaling behavior of a managed type can differ between COM calls and System.Runtime.InteropServices.DllImportAttribute calls or delegate callback calls. You can use the System.Runtime.InteropServices.MarshalAsAttribute attribute to specify a marshaling type other then the default. You must also use the ref keyword to identify parameters that are expected to be pointers in native code.
The following example shows a signature entry for a PInvoke call:
1) [pinvokeimpl][preservesig] 2) bool PlatformDetector::SystemParametersInfo(uint , uint , System.Text.StringBuilder , uint ); 3) BOOLEAN (I1_WINBOOL_VAL) SystemParametersInfo(unsigned int (U4_VAL) , unsigned int (U4_VAL) , WCHAR * (STRINGBUILDER_LPWSTR) , unsigned int (U4_VAL) );
The following example shows a signature entry for a delegate callback.
1) [preservesig][delegate] 2) int WndProc::Invoke(WndProc , IntPtr , uint , uint , int ); 3) int (I4_VAL) (*)(INT_PTR (I_VAL) , unsigned int (U4_VAL) , unsigned int (U4_VAL) , int (I4_VAL) )
The following example shows a signature entry for a native-to-managed COM function call, where the runtime returns a failure HRESULT in the event of a managed exception.
1) [no flags] 2) int N2MDualComponentImp.IN2MDualInterface::GetInt(N2MDualComponentImp.IN2MDualInterface This); 3) HRESULT GetInt(IN2MDualInterface *(INTF_VAL) this, [retval] int (I4_VAL) retval);
You should search the interop log file for the keywords ‘ERROR’ and ‘WARNING’. Some situations can cause error messages to be recorded in the log file, which can be especially useful when investigating issues that involve interoperating with native components and DLLs for which the native source code is not available. You can use error messages to help diagnose the following issues:
Native-to-managed function calls: