Exception 0x406d1388
-
I have a large, complex app MFC with /CLR, Unicode, uses several dll's including one .NET assembly. Release build works perfectly on dev machine. Deployed to target machine with .NET Framework 2.0 and all necessary dependencies. It crashes immediately every time in
kernel32.dllwith exception0x406d1388. Further examination with depends.exe shows that the caller wasadvapi32.dllbut I can't get much more info. This happens on WinXP SP2 and on Win2k SP4. It seems that the exception is the one normally used to set a thread name so it makes no sense to me that it's causing a crash. :confused: If I run the app (same release version) by remote debugging from VS2005 it all works properly. :mad: I've built a simpler test app to try to reproduce use as much as possible of the same environment (MFC, CLR, dll's and so on) and it also works perfectly. :(( Please can someone give me a clue???????? Regards, Phil -
I have a large, complex app MFC with /CLR, Unicode, uses several dll's including one .NET assembly. Release build works perfectly on dev machine. Deployed to target machine with .NET Framework 2.0 and all necessary dependencies. It crashes immediately every time in
kernel32.dllwith exception0x406d1388. Further examination with depends.exe shows that the caller wasadvapi32.dllbut I can't get much more info. This happens on WinXP SP2 and on Win2k SP4. It seems that the exception is the one normally used to set a thread name so it makes no sense to me that it's causing a crash. :confused: If I run the app (same release version) by remote debugging from VS2005 it all works properly. :mad: I've built a simpler test app to try to reproduce use as much as possible of the same environment (MFC, CLR, dll's and so on) and it also works perfectly. :(( Please can someone give me a clue???????? Regards, PhilYou will need to get symbols and get a stack trace so you can find out what the actual call is. 8bc7c0ec02c0e404c0cc0680f7018827ebee
-
You will need to get symbols and get a stack trace so you can find out what the actual call is. 8bc7c0ec02c0e404c0cc0680f7018827ebee
Thanks for the reply. That's proving $%^@# difficult! The problem seems to occur at some stage in the runtime initialisation. If I run the programme under VS2005 it won't fail. I set it to break on the exception but it never sees it. If I jit debug it the process wakes up and continues faultless as soon as the debugger attaches. WinDbg sometimes sees the exception but I can't get any sense out of the call stack. I can't set breakpoints using WinDbg because it corrupts the code somehow and complains about "invalid x86 breakpoint in IL stream". Any ideas ... ? Regards, Phil
-
I have a large, complex app MFC with /CLR, Unicode, uses several dll's including one .NET assembly. Release build works perfectly on dev machine. Deployed to target machine with .NET Framework 2.0 and all necessary dependencies. It crashes immediately every time in
kernel32.dllwith exception0x406d1388. Further examination with depends.exe shows that the caller wasadvapi32.dllbut I can't get much more info. This happens on WinXP SP2 and on Win2k SP4. It seems that the exception is the one normally used to set a thread name so it makes no sense to me that it's causing a crash. :confused: If I run the app (same release version) by remote debugging from VS2005 it all works properly. :mad: I've built a simpler test app to try to reproduce use as much as possible of the same environment (MFC, CLR, dll's and so on) and it also works perfectly. :(( Please can someone give me a clue???????? Regards, PhilEureka! I have found it! After hours of trying various debuggers and debugging strategies, countless cups of good strong tea and not a few words of frustration and annoyance I have located and fixed the problem. Buried deep in my own initialisation code, in a place I haven't visited for years and had forgotten all about is a call to a function called
SetThreadNamewhich uses exception 0x406d1388 :-O. This was being compiled as managed code so the framework was seeing the exception even before the catch block in the same function. The solution was simply to mark that function asunmanaged(and then drink more tea :) ). Phil -
You will need to get symbols and get a stack trace so you can find out what the actual call is. 8bc7c0ec02c0e404c0cc0680f7018827ebee
I have fixed it. Please see my reply to the original post for details. Thanks again for your interest. Phil
-
Eureka! I have found it! After hours of trying various debuggers and debugging strategies, countless cups of good strong tea and not a few words of frustration and annoyance I have located and fixed the problem. Buried deep in my own initialisation code, in a place I haven't visited for years and had forgotten all about is a call to a function called
SetThreadNamewhich uses exception 0x406d1388 :-O. This was being compiled as managed code so the framework was seeing the exception even before the catch block in the same function. The solution was simply to mark that function asunmanaged(and then drink more tea :) ). PhilNever use managed code :) 8bc7c0ec02c0e404c0cc0680f7018827ebee