Thread overview
Profiling Windows App and DLL
Jul 17, 2017
Igor
Jul 23, 2017
Rainer Schuetze
Jul 23, 2017
Guillaume Piolat
July 17, 2017
Is there a known limitation in profiling these or am I doing something wrong?

When I try to run my application from VisualD (x64 build) with -profile switch I just get Access Violation reported on WinMain function (actual declaration, it doesn't enter its body). If I build it with dub build --build=profile and then try to run it nothing happens, like it doesn't run at all.

If I only add -profile switch on DLL part of the application I get the same Access Violation on DllMain.

I also tried "Very Sleepy" profiler but it only shows symbols for main application and not for the DLL that it loads which is also built with debug info.
July 23, 2017

On 17.07.2017 22:36, Igor wrote:
> Is there a known limitation in profiling these or am I doing something wrong?
> 
> When I try to run my application from VisualD (x64 build) with -profile switch I just get Access Violation reported on WinMain function (actual declaration, it doesn't enter its body). If I build it with dub build --build=profile and then try to run it nothing happens, like it doesn't run at all.
> 
> If I only add -profile switch on DLL part of the application I get the same Access Violation on DllMain.

The problem seems to be that the compiler only excludes C main from being instrumented for profiling. This causes WinMain/DllMain to also call the tracing functions before the runtime had a chance to be initialized by Runtime.initialize().

A workaround could be to compile the respective module without -profile, and then link it as an object file to the rest of the code.

> 
> I also tried "Very Sleepy" profiler but it only shows symbols for main application and not for the DLL that it loads which is also built with debug info.

You can also use the "Performance profiler" from within Visual Studio.
July 23, 2017
On Monday, 17 July 2017 at 20:36:58 UTC, Igor wrote:
> I also tried "Very Sleepy" profiler but it only shows symbols for main application and not for the DLL that it loads which is also built with debug info.

Something that works very well is CPU profiling with CodeXL. It used to be an underwhelming sampling profiler, until a few years ago.