When you face a problem and our support team is unable to reproduce it on our side, we often ask you for a debug log.
Logs with release DLLs
With the 2.6 version, you can collect logs with release DLLs of the SDK. With this version, you have a specific DLL in the installer of the SDK - Medialooks.MLLog.x64.dll and Medialooks.MLLog.x86.dll. Once the DLL is registered on a machine where you have a problem, you have the following branch in the system registry:
Computer\HKEY_CURRENT_USER\SOFTWARE\Medialooks\MFormats\MFFactory\MLLog
It contains the following properties
| Name | Default value | Description |
|---|---|---|
| log.files | 10 | Limits the number of LOG files collected from a single module in a target folder. |
| log.modules |
Lists the modules to collect logs from. Use "all" to collect from all the DLLs. Use "mserver" to collect logs from external processes (decoding or encoding). Use a name of a DLL to collect from a specific module, e.g. "Device.DS", or "Mixer", or "MFWriter". To collect logs from several modules at the same time, list them with a comma as a separator, e.g. "Plugin.CG, MFReader". |
|
| log.path | Path to a folder to store the logs. If empty, the log is stored in the executable folder (where the main EXE is stored). | |
| log.roll | 100mb | Limits the file size of each log. Once a log reaches the limit, a new file is generated. Set 0 to disable the rolling. |
| log.verbosity | 0 |
Log level. Possible values:
|
So, for example, you have a problem with a file playback. You can check the DLL name of an object -- either by checking the redistributed files or with a code like this
myReader.PropsGet("dll-path", out string dllPath);
Then you might use a file name (e.g. "Medialooks.MFReader.x86.dll") or a shorter name of the file (without the "Medialooks." and "x86.dll") -- "MFReader", and use this as a value of the log.modules property. Then, set a path to a target folder with the log.path. Now you are good to go to collect the logs. Start your application, get the problem reproduced -- at this moment, the logs should be available. Close the application, and share the logs with our support engineers.
Debug log with Debug DLLs registration
Here is a description of gathering a log about a problem:
- Download debug DLLs the support team sends to you.
- Put the DLLs near the original ones. For example, if you need to create a log for MPlaylistD.dll, you should put the file in the same folder where the MPlaylistPXT.dll is located.
- Register the debug DLL files.
- Download a logging tool. You can download it in this article.
- Extract the archive into any folder.
- Run either register32.bat (for x86 DLLs) or register64.bat (for x64 DLLs). Type the name of an output log file and click the "Save" button. For multi-threading applications, you can select the "Append process name to log file name" option. Once enabled, you have several output log files.
- Run your application and reproduce the error. Sometimes you may have debug assertions. Try to ignore them by pressing the "Ignore" button (this information is also included in the output log file).
- Close the application.
- To disable logging you should remove the following registry branch for x86:
[HKEY_CURRENT_USER\SOFTWARE\_DSTLLOG]
and for x64:
[HKEY_CURRENT_USER\SOFTWARE\_DSTLLOG64] - Zip the output log file and send the archive back to the support team.
Sometimes output log file is too big for sending via email. In this case, there is a LogEditor utility (included in the logging tool archive - attached to this article). You can use it to cut some part of the log file (usually the last 100-150 MB) to make it shorter and smaller.
Debug log with Debug DLLs with manifest-based applications
If you use a manifest-based type of redistribution then you can't register a single DLL to make a log because the manifest uses a reference to a file using a path specified in the manifest.
In this case, you should copy the debug DLLs to the redistribution folder and replace the existing one with the debug. A good way for this is to rename the old one (to use it later) and use the original name for renaming the debug DLL - so the manifest has the same path to the DLL and you don't need to modify it.
The next steps starting from point 6 are the same.