none
.Net Profiler - Ways to Debug the Profiler RRS feed

  • Question

  • My instrumentation .Net profiler which will monitor only the w3wp.exe (Web applications) is crashing at some random scenario. 

    During my development phase i have faced few crashed which i identified by writing logs over the code flow. But now the crash occurs(it makes the w3wp.exe to stop) and it is consuming soo much hours to corner the faulty code. Still i am trying to identify it. 

    I am sure the C# helper assembly is not the reason for the crash. But the C++ dll only has some crash when i handle the profiled data. 

    Is there any efficient way to debug the profiler dll other than logging ? So that it i can get at least the stacktrace where the code is crashing..!

    Thanks,

    ./Selva


    Monday, January 2, 2017 4:50 AM

Answers

  • Also,I tried to set break point to check if the debug symbols are loaded. The breakpoints couldn't be set there.

    You tried to set the breakpoint where? In the native code or your managed assembly?

    You should be able to pause the process and check the 'Modules' window (Debug > Windows > Modules) to see if symbols were loaded.

    I guess the process that gets attached to VS2012 should itself be in debug mode ( (i.e) the w3wp.exe should be in debug mode). In my case only the Profiler dll is in debug mode . So i think the debug symbols are not loaded.

    It's not a process level thing, it's the modules you want to debug should be compiled in debug (the profiler module). If you use a release build then it would affect your ability to place break points, step through code and see the current value of a variable. I wouldn't expect it to affect your ability to break on exception.

    If the process terminates without raising an exception, then it might be terminating by some other means.

    • Environment.FailFast() - If this is the cause, then it should be recorded in the application event log.
    • ExitProcess - This is unlikely to leave anything in the event log, but you might be able to place a breakpoint in the method (open the disassembly window, enter "kernel32.dll!ExitProcess" into the address field and place a break point on the selected instruction).
    • TerminateProcess - I wouldn't be surprised if this recorded something in the event log, particularly if terminated by another process, but I haven't seen anything to say so.

    Am i rite?  And how can i debug using the release build..?

    Your better off trying with a debug build, but if you must use a release build (ie. if the bug doesn't happen in debug builds) then the 'how' shouldn't really change much, you still start the process and attach the debugger in the same way.

    • Proposed as answer by Kristin Xie Friday, January 6, 2017 3:10 AM
    • Marked as answer by Selva VS Friday, January 6, 2017 11:22 AM
    Thursday, January 5, 2017 9:57 AM

All replies

  • Have you tried attaching a (native) debugger and setting it to break on exception? (Win32, C++ and CLR exceptions)
    Monday, January 2, 2017 10:21 AM
  • Do u mean attaching a debug mode built Profiler dll with w3wp.exe and attaching the w3wp.exe with VisualStudio ?? 
    • Edited by Selva VS Monday, January 2, 2017 12:15 PM
    Monday, January 2, 2017 12:14 PM
  • Yes, run the web server with a debug version of your profiler and then debug the process with VisualStudio. If you can't reproduce the problem with a debug build of your profiler, then you should still be able to debug with a release build ... it just gets more difficult.
    Monday, January 2, 2017 1:07 PM
  • I have attached the visual studio with the w3wp process (remotely) . When the unhandled exception(crash) occurs it is getting detached from the process. 

    Also,I tried to set break point to check if the debug symbols are loaded. The breakpoints couldn't be set there. 

    I guess the process that gets attached to VS2012 should itself be in debug mode ( (i.e) the w3wp.exe should be in debug mode). In my case only the Profiler dll is in debug mode . So i think the debug symbols are not loaded.

    Am i rite?  And how can i debug using the release build..?


    • Edited by Selva VS Tuesday, January 3, 2017 11:28 AM
    Tuesday, January 3, 2017 11:28 AM
  • Hi Selva,

    >>My instrumentation .Net profiler which will monitor only the w3wp.exe (Web applications) is crashing at some random scenario. 

    I'd recommend you to run a profiler on your code,

    There are a lot of different ways to troubleshoot ASP.NET issues.  Please refer to Profilers and ASP.NET and get help from Visual Studio's Code Analyze tools. See if you're disposing connections, or you have any infinite loops. It's usually us, not the framework or the hardware. As you may know many logging libraries are available for dotnet, I would suggest you take a look at NLog.  

    Best regards,

    Kristin


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, January 4, 2017 2:25 AM
  • Also,I tried to set break point to check if the debug symbols are loaded. The breakpoints couldn't be set there.

    You tried to set the breakpoint where? In the native code or your managed assembly?

    You should be able to pause the process and check the 'Modules' window (Debug > Windows > Modules) to see if symbols were loaded.

    I guess the process that gets attached to VS2012 should itself be in debug mode ( (i.e) the w3wp.exe should be in debug mode). In my case only the Profiler dll is in debug mode . So i think the debug symbols are not loaded.

    It's not a process level thing, it's the modules you want to debug should be compiled in debug (the profiler module). If you use a release build then it would affect your ability to place break points, step through code and see the current value of a variable. I wouldn't expect it to affect your ability to break on exception.

    If the process terminates without raising an exception, then it might be terminating by some other means.

    • Environment.FailFast() - If this is the cause, then it should be recorded in the application event log.
    • ExitProcess - This is unlikely to leave anything in the event log, but you might be able to place a breakpoint in the method (open the disassembly window, enter "kernel32.dll!ExitProcess" into the address field and place a break point on the selected instruction).
    • TerminateProcess - I wouldn't be surprised if this recorded something in the event log, particularly if terminated by another process, but I haven't seen anything to say so.

    Am i rite?  And how can i debug using the release build..?

    Your better off trying with a debug build, but if you must use a release build (ie. if the bug doesn't happen in debug builds) then the 'how' shouldn't really change much, you still start the process and attach the debugger in the same way.

    • Proposed as answer by Kristin Xie Friday, January 6, 2017 3:10 AM
    • Marked as answer by Selva VS Friday, January 6, 2017 11:22 AM
    Thursday, January 5, 2017 9:57 AM