Quantcast
Channel: Visual Leak Detector for Visual C++ 2008-2015
Viewing all articles
Browse latest Browse all 704

Edited Unassigned: Main application fails to run with VLD [10603]

$
0
0

I am reposting an old issue (https://vld.codeplex.com/workitem/10597) with more detail information.

VLD V2.5 is installed under the default folder : C:\Program Files (x86)\Visual Leak\Detector.
Both 32/64 versions correctly installed with the following files:
- C:\Program Files (x86)\Visual Leak Detector\bin\Win32\dbghelp.dll
- C:\Program Files (x86)\Visual Leak Detector\bin\Win32\vld_x86.dll
- C:\Program Files (x86)\Visual Leak Detector\bin\Win32\Microsoft.DTfW.DHL.manifest
- C:\Program Files (x86)\Visual Leak Detector\bin\Win64\dbghelp.dll
- C:\Program Files (x86)\Visual Leak Detector\bin\Win64\vld_x64.dll
- C:\Program Files (x86)\Visual Leak Detector\bin\Win64\Microsoft.DTfW.DHL.manifest

In C:\M folder, there are 3 exe files. They are:
- C:\M\M.exe => Main program with main UI
- C:\M\Q.exe => Standalone Database management program with DB-related UI
- C:\M\t.exe => Background COM worker process acting as the database engine server with no UI

They all comprise one application working closely together.
M.exe can be thought of as the main program with UI. Q.exe and t.exe serve M.exe.
Q.exe is another program running standalone and/or serving M.exe.
t.exe is a worker COM process implementing many coclasses serving both M.exe and Q.exe.
M.exe and Q.exe CoCreateInstance's those coclasses to communicate with t.exe.
t.exe itself also CoCreateInstance's its own coclasses when necessary.
Running M.exe and/or Q.exe automatically launches t.exe.

And C:\M folder, there is a dbghelp.dll (V6.1.72.2) belonging to this application. I guess this could be a privately customized dbghelp.dll file. And there exists no Microsoft.DTfW.DHL.manifest file in C:\M folder.

There are 6 dll files involved in running M.exe, Q.exe and t.exe. They are:
- C:\M\PF.dll
- C:\M\PR.dll
- C:\M\SP.dll
- C:\M\JS.dll
- C:\M\S\S.dll
- C:\M\D\F.dll

All these are built with vld.

And S.dll is special because it is injected into M.exe, Q.exe, and t.exe before running.
When running any of these exes (order does not matter), S.dll is the first dll loaded into their process memory areas.

And S.dll loads the first 4 dlls: PF/PR/SP/JS.

When t.exe loads S.dll, S.dll's DllMain calls exported functions from PF/PR/SP/JS.
M.exe or Q.exe do not directly calls exported functions from PF/PR/SP/JS.

[1] Scenario 1 => Running Q.exe alone
In this case, t.exe is automatically launched to server Q.exe.
And everything works fine.

[2] Scenario 2 => Running M.exe alone
In this case, t.exe is automatically launched to serve M.exe.
In this case, M.exe always fails to run with the following error message box:

> [Microsoft Visual C++ Runtime Library]
> Runtime Error!
>
> Program: C:\M\M.exe
>
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact applicatioin's support team for more information.

Finally, I checked each of the above 6 dll files to see which one causes this issue.
4 of them linked with vld were culprits:
- C:\M\PF.dll
- C:\M\PR.dll
- C:\M\SP.dll
- C:\M\S\S.dll
Even if any one of these 4 files is linked with vld, M.exe fails to run.

I am totally lost why this happens only when M.exe is running.

I hope the developer of VLD remotely connects to my PC to directly see this issue.
I would run TeamViewer and wait for your connect.
Just give me the date/time (in GMT) you want to connect.
I am located in Seoul, Korea (GMT+09).

VLD almost always works great but in this kind of complicated scenario, it mostly fails.
I guess VLD never encountered this complicated situation before.
Please help me with fixing this issue so that I can freely work with VLD.

Best
HR




Viewing all articles
Browse latest Browse all 704

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>