Hello Asia,
We have the exact same scenario: we are profiling w3wp.exe with the dotTrace version 5.3 build 1114. And we have about 50% of time shown as "unsafe stack walking".
We started with profiling the application using RemoteAgent, then installed dotTrace locally on the server and profiled locally - with the same result. At the same time, we don't have this "unsafe stack walking" when we profile in a development environment - when the application is run using Visual Studio development web server. So dotTrace seems to have difficulty collecting sampling info for an application being run using IIS.
But the main question for us now: is the time shown as "unsafe stack walking" actually spent in our code, and it's just we can't have details on where the time is spent? Or can it be that the time is spent on some infrastructure overhead introduced by IIS, or something?
UPD: just built a piece of code we want to profile into an .exe and profiled it on the server. Now we have up to 70% of the execution time spent on "unsafe stack walking". So it's not IIS with its runtime causing the issue.
Development workstations vary: have different operating systems installed (including server types of OS), different number of cores and amount of memory. So it doesn't seem to depend on OS. The framework versions are also the same. But all of the developer machines are phisical ones, and the servers are virtual.
UPD2: We seem to have sorted it out: the console application we built for testing purpose profiles OK when it is built for the x86 platform and have ~50% of "unsafe stack walking" when it's built for x64. The execution time is about the same so at least we know that the application is not being stuck for some weird reason when is run under IIS.
What would be your plans on fixing it?
Thanks,
Dmitry
