Renaming a C++ thread when running under Visual Studio 2010 extension package

I'm using the following code (from MSDN) to rename a C++ thread:

#include <windows.h>
const DWORD MS_VC_EXCEPTION=0x406D1388;

#pragma pack(push,8)
typedef struct tagTHREADNAME_INFO
{
   DWORD dwType; // Must be 0x1000.
   LPCSTR szName; // Pointer to name (in user addr space).
   DWORD dwThreadID; // Thread ID (-1=caller thread).
   DWORD dwFlags; // Reserved for future use, must be zero.
} THREADNAME_INFO;
#pragma pack(pop)

void SetThreadName( DWORD dwThreadID, char* threadName)
{
   THREADNAME_INFO info;
   info.dwType = 0x1000;
   info.szName = threadName;
   info.dwThreadID = dwThreadID;
   info.dwFlags = 0;

   __try
   {
      RaiseException( MS_VC_EXCEPTION, 0, sizeof(info)/sizeof(ULONG_PTR), (ULONG_PTR*)&info );
   }
   __except(EXCEPTION_EXECUTE_HANDLER)
   {
   }
}

And it is working great overall. However, when trying to execute this code in Visual Studio (2010) extension package, I get the following unhanded exception and the name of the thread doesn't change:

System.Runtime.InteropServices.SEHException occurred Message: External component has thrown an exception.

Anyone has any clue what's going on there? I realize there might be some issues with changing a thread that way from extensions, however, it is undocumented and it seems to be working fine from a standard add-开发者_JS百科in.

Thanks!

---

I'm not certain whether this is the cause of your problem but according to this MSDN documentation the SetThreadName function only applies to native code. Judging from the exception you're seeing you're compiling with the /clr option so you should probably use the managed code equivalent of this. Follow the link under the See Also section in the first link, it shows the snippet to use for managed code.

HTH, Ashish.

---

Sounds familiar. Here's what the insides of our SetThreadName looks like (in a mixed native C++, C++/CLI, C# app):

#pragma warning(disable: 6312 6322)
        __try
        {
            RaiseException( 0x406D1388, 0, sizeof(info) / sizeof(DWORD), (DWORD*)&info );
        }
        // don't implement MSDN's suggested fix for 6312 here - it causes a nasty unhandled exception
        // to bubble up into managed code. Disable the compiler warning instead.
        __except(EXCEPTION_CONTINUE_EXECUTION)
        {
        }
#pragma warning(default: 6312 6322)