There is a winforms application that uses calls from native c ++ libraries as well. In search of problems in these libraries, the application was launched under the gdb debuggers on Windows. However, the debugger revealed a segmentation problem in the stream, which, apparently, relates to managed code.
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 287244.0x59c74] 0x70f34bb6 in ?? () from C:\Windows\assembly\NativeImages_v4.0.30319_32\System\d03eb8a47500f40d54 28f9c6875f8e56\System.ni.dll
It is not very clear what this could mean and what further steps should be taken to find the source of the error.
Back trace debugger attached:
(gdb) bt #0 0x70f34bb6 in ?? () from C:\Windows\assembly\NativeImages_v4.0.30319_32\System\d03eb8a47500f40d54 28f9c6875f8e56\System.ni.dll #1 0x0b6e3356 in ?? () #2 0x70a5ebf5 in ?? () from C:\Windows\assembly\NativeImages_v4.0.30319_32\System\d03eb8a47500f40d54 28f9c6875f8e56\System.ni.dll #3 0x70a6e04c in ?? () from C:\Windows\assembly\NativeImages_v4.0.30319_32\System\d03eb8a47500f40d54 28f9c6875f8e56\System.ni.dll #4 0x7161b386 in ?? () from C:\Windows\assembly\NativeImages_v4.0.30319_32\mscorlib\affcb83bba04f782 c2586a1788330891\mscorlib.ni.dll #5 0x7161b341 in ?? () from C:\Windows\assembly\NativeImages_v4.0.30319_32\mscorlib\affcb83bba04f782 c2586a1788330891\mscorlib.ni.dll #6 0x70a6c81f in ?? () from C:\Windows\assembly\NativeImages_v4.0.30319_32\System\d03eb8a47500f40d54 28f9c6875f8e56\System.ni.dll #7 0x70a5eb7e in ?? () from C:\Windows\assembly\NativeImages_v4.0.30319_32\System\d03eb8a47500f40d54 28f9c6875f8e56\System.ni.dll #8 0x70ebbed2 in ?? () from C:\Windows\assembly\NativeImages_v4.0.30319_32\System\d03eb8a47500f40d5- 428f9c6875f8e56\System.ni.dll #9 0x70a5ebf5 in ?? () from C:\Windows\assembly\NativeImages_v4.0.30319_32\System\d03eb8a47500f40d54 28f9c6875f8e56\System.ni.dll #10 0x70a6c82e in ?? () from C:\Windows\assembly\NativeImages_v4.0.30319_32\System\d03eb8a47500f40d54 28f9c6875f8e56\System.ni.dll #11 0x70a5eb7e in ?? () from C:\Windows\assembly\NativeImages_v4.0.30319_32\System\d03eb8a47500f40d54 28f9c6875f8e56\System.ni.dll #12 0x70ea49ac in ?? () from C:\Windows\assembly\NativeImages_v4.0.30319_32\System\d03eb8a47500f40d54 28f9c6875f8e56\System.ni.dll #13 0x716bfccf in ?? () from C:\Windows\assembly\NativeImages_v4.0.30319_32\mscorlib\affcb83bba04f782 c2586a1788330891\mscorlib.ni.dll #14 0x716bfb9a in ?? () from C:\Windows\assembly\NativeImages_v4.0.30319_32\mscorlib\affcb83bba04f782 c2586a1788330891\mscorlib.ni.dll #15 0x725e366f in ?? () from C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll #16 0x725ed376 in ?? () from C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll #17 0x726bc6bc in ?? () from C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll #18 0x725ed6b7 in ?? () from C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll #19 0x725ed721 in ?? () from C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll #20 0x725ed7ee in ?? () from C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll #21 0x725ed868 in ?? () from C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll #22 0x726bc650 in ?? () from C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll #23 0x726bb4cf in ?? () from C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll #24 0x726e60d1 in ?? () from C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll #25 0x7675338a in KERNEL32!BaseThreadInitThunk () from C:\Windows\syswow64\kernel32.dll #26 0x77289902 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll #27 0x772898d5 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll #28 0x00000000 in ?? ()
Debugging is aggravated by the fact that the problem is relatively rare (~ 1 time in 10 hours of work). All this time, the program works in the same mode, i.e. no (unknown) of a particular action that would allow to postpone or approximate the moment of error occurrence when working in a given mode.
Does anyone have any ideas?
