When a crash occurs on Windows Client or Server Agent, use WinDbg to catch(capture) the call stack.
- Download and install WinDbg (https://developer.microsoft.com/en-US/windows/downloads/windows-10-sdk); during the installation, select the 'Debugging Tools for Windows' checkbox only. You can also download an old build from http://wcbuild.gladinet.com/releases/windbg/X86-Debuggers-And-Tools-x86_en-us.msi.
- For Windows Client/Server Agent, use 32-bit WinDbg if possible. The core components are built-in 32-bit environment.
- start WinDbg
- if the issue is on Windows Client side, start WinDbg as regular user
- if the issue is on Server Agent side, start WinDbg as Administrator
- Contact Support (email@example.com) with the Desktop Client version to send you the Symbol files corresponding to the Client installed.
- Create a local folder C:\symbols, to store the symbol files downloaded from Microsoft (symbols from the Client can also be saved on this folder).
- From the WindDbg go to 'File' -> 'Symbol File Path', set symbol path to 'srv*C:\symbols*https://msdl.microsoft.com/download/symbols;C:\symbols\pdb1234' (the last part corresponds to the folder the Client's Symbols are saved)
- Windows Client:
In WinDbg, go to File, Open Executable. Go to the Windows Client installation folder and select 'CoDesktopClient.exe'. Type '/child' as Arguments. Click 'Open', to launch the Windows Client in WinDbg.
When start Windows Client like this, do NOT start WinDbg as administrator first.
- Server Agent:
In WinDbg, press F6, select the process 'GladGroupSvc.exe' and click 'OK'. It will attach WinDbg to the process.
- Type 'g' to continue. The command line field will show '*BUSY* Debuggee is running…'.
- If the Windows Client/Server Agent crashes, it will crash in WinDbg. You’ll see the command line is ready to take command, to analyze the crash.
- If you are running 64-bit Windbg, run '!wow64exts.sw' first
- Type 'kb' first, then '~*kb' and then !analyze -v to get thread info. Save the output in WinDbg (Edit -> Write Window Text to File).
- In some scenarios, the application will call TerminateProcess (NTDLL) first before the crash. In that case, '~*kb' only returns one thread.
- when '~*kb' only returns one thread, need to stop WinDbg. Follow the above process to re-launch WinDbg, start the client in WinDbg/attach to Server Agent service process
- Before type 'g' to continue, run 'x kernel32!TerminateP*', to get the exact name. For example:
0:090> x kernel32!TerminateP*
776289b0 KERNEL32!TerminateProcessStub (<no parameter info>)
Run 'bp kernel32!TerminateProcessStub', to set a breakpoint on the call 'kernel32!TerminateProcessStub'. This way, we can get all the thread information, instead of only one thread.
Run 'g' to resume the process. When it crashes, run 'kb' and '~*kb' and save the WinDbg output (Edit -> Write Window Text to File).
- Type '.dump /ma c:\temp\crash.dmp', to create dump. The dump file will be created under c:\temp. If the folder doesn't exist, please change the path. Zip the dump file and keep it, in case we need to retrieve more info from the dump.
- Now you can close WinDbg.
- Send the saved output and the dump file to Gladinet support.