Identifying threads in VS .NET 2003

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • hjazz
    New Member
    • Nov 2009
    • 5

    Identifying threads in VS .NET 2003

    Hi all,

    I'm converting a Linux program to a Windows program using Visual Studio .NET 2003. The code was written using pthread.

    I have a "First-chance exception at 0x100084c8 in project.exe: 0xC0000005: Access violation reading location 0x000001dc" error that is causing my program to crash, and all but one thread "has exited with code 0 (0x0)." The one thread (0xfe4) exited with code -1073741819 (0xc0000005). I read that if threads exited with code 0, then everything is fine. I'm guessing the one thread that did not caused the error, especially since the same code 0xC0000005 showed up.

    As there are groups of threads doing different tasks, I wish to track down the thread that did not exit correctly, so as to debug the program. Is there a way to identify which thread it is, like using the (0xfe4) value?

    Thank you.

    Regards,
    Rayne
  • RRick
    Recognized Expert Contributor
    • Feb 2007
    • 463

    #2
    Have you tried the debugger with this? I assume VS 2003 knows how to deal with multiple threads and can stop on errors.

    Access violations are caused by bad pointers, typically a null pointer. Since the address is low, the location 0x000001dc might be an offset into a structure or class. If its not too difficult, I would check the class pointer values in your code.

    Comment

    • Banfa
      Recognized Expert Expert
      • Feb 2006
      • 9067

      #3
      A first chance exception is normally given when you debug the program. It goes something a little like this
      1. Exception Raised
      2. Exception passed to debugger for first chance exception, user has a chance to interact if they wish or can just continue.
      3. If they continue the exception is passed to the program, the program may handle the exception.
      4. If the program does not handle the exception the exception gets passed back to the debugger again for a second chance exception.


      The point is that if your program is handling the exception first chance exceptions may well not be a serious issue.

      However when you get an exception and the debugger pauses execution you should simply be able to display the threads dialgue box to see which thread is running and a quick double click on it should take you to the code that is running. If it is a system call and no code is available then the call stack dialog will enable you to step back up the call stack until you get to the code of your program.

      Comment

      Working...