The profiler is unable to start an EXE correctly because the manner in which the EXE is started renders it unable to find required configuration files. The working folder setting, which I would think would set the working folder, apparently does nothing. Why is there an option to start an EXE if the profiler is not able to start an EXE that makes use of its .config file?

So what is not available in the profiling of an already running process? The UI says that it's not as detailed, but I don't see any indication of what that actually means.

Starting the profiled application using the command "Profile application" should work without problems and the .config file should be correctly read. The location of the configuration file is not dependent on the working directory, it will be read from the directory of the application executable. I have tested to start an application using the profiler in all possible ways, and I have not been able to find a case where the working directory is not correctly initialized. How are you starting the profiled application, and it what way does it fail to run?

If there's a problem with application startup, this is something we want to fix as soon as possible. We can get better information about this problem if you send us log-files from the profiler. You can create log-files by using the command line below. This will create a set of log-files in the c:\MemProfilerLogs directory.

The ProfilerLog.txt file can become very large, but it compresses well. You can contact us at support@scitech.se for information on how to send the log-files to us.

When attaching to a process, the profiler will not be able to detect the instance allocations, so no information about allocation call stacks will be presented. Furthermore, it will not have full information about all classes in the process so all static fields will not be known to the profiler. All roots will be detected though, but not all of them will be mapped to the corresponding static field.