A friend advised me their copy of CyberLink PowerProducer kept crashing when rendering video. The operating system was Windows 7 so first I got a quick look at the report.wer which is located in folders named after the process crashing/hanging in the ReportQueue and ReportArchive folders under %localappdata%\microsoft\windows\wer
These files can be opened in notepad, in some cases they are all you need to give you a clue to a solution. We can see the version 184.108.40.2062 is not the latest version, so one obvious fix to update the application, however the crashes continued.
We also see the faulting module is TemplateMgr3U.dll – from the name we might guess this loads templates of some kind, and maybe there is a template causing this crash. So we tried removing custom templates but no luck.
Sig.Name=Fault Module Name
Sig.Name=Fault Module Version
Sig.Name=Fault Module Timestamp
DynamicSig.Name=Additional Information 1
DynamicSig.Name=Additional Information 2
DynamicSig.Name=Additional Information 3
DynamicSig.Name=Additional Information 4
UI=G:\Program Files (x86)\CyberLink\PowerProducer\Producer.exe
UI=PowerProducer has stopped working
UI=Windows can check online for a solution to the problem.
UI=Check online for a solution and close the program
UI=Check online for a solution later and close the program
UI=Close the program
So then we launched the program with WinDbg from the Windows SDK, which is available from the Microsoft Website, by using the File –> Open Executable option.
The debugger will always “break” on process start, so we had to hit g [enter] to continue up till our crash…
Eventually it crashed with this message in the debugger:
(fb4.9f0): Stack overflow – code c00000fd (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=000000b0 ebx=02160000 ecx=02160000 edx=40000062 esi=00000000 edi=04f7fd00 eip=7711defe esp=00092fc8 ebp=00093088 iopl=0 nv up ei pl nz na po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210202 ntdll!_SEH_prolog4+0x1a: 7711defe 53 push ebx
Continuing did nothing…
However there wasn’t an immediately obvious cause to the stack overflow. So in this case we downloaded Application Verifier
Once Application Verifier was installed, we launched it, and added the Producer.exe to it, with the options
- Basic (all)
- Miscellaneous – StackTrash
Keep in mind the purpose of application verifier is to put additional checks on an application, that in normal use would be far too time consuming. Your process will likely run noticeably slower with verifier enabled. In addition you should always run App Verifier enabled apps under a debugger, as the verifier causes them to crash more frequently. In this case we hope that app verifier will identify some bad behavior that might lead up to the stack overflow and give us a clue to the root cause…
With application verifier enabled we got a crash occurring much sooner in the application:
(1de8.183c): Access violation – code c0000005 (!!! second chance !!!) eax=4df88fe8 ebx=00000002 ecx=4110cfd0 edx=3eb21970 esi=3e358fe8 edi=4af6efe8 eip=387dada0 esp=00180650 ebp=001806ac iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210246 amdocl!clGetSamplerInfo+0x3a8380: 387dada0 8b01 mov eax,dword ptr [ecx] ds:002b:4110cfd0=????????
Here we see the module/image (DLL) and the function called clGetSamplerInfo
A lookup on amdocl.dll (and can also be guessed by the name) it was part of the AMD Video driver installation.
A check on the video card model, AMD Radeon™ HD 6950 Graphics card, we found that others had crashes on rendering video: http://devgurus.amd.com/thread/154570
The drivers for the graphic card were updated to the latest version from the AMD website, and happy days…rendering back in business.