Ситуация: имеется нативное приложение, которое в определенный момент инстанциирует CLR-хост (через
CorBindToRuntimeEx , версия CLR - 4.0.30319, build flawor - workstation, флаги запуска - STARTUP_CONCURRENT_GC и STARTUP_LOADER_OPTIMIZATION_SINGLE_DOMAIN). Далее создается отдельный домен, и в него загружается сборка с COM-visible классами и интерфейсами, посредством которых осуществляется взаимодействие управляемого и неуправляемого кода. Всё работает прекрасно, за одним небольшим исключением: на ОС старше висты (WinXP, windows server 2000) всё это просто молча падает. Сначала в консольном выводе было замечено, что Process is terminated due to StackOverflowException - но ни в неуправлемом, ни в управляемом коде нет ни рекурсии, ни чего-л., что могло бы привести к SOF. Попробовал описанное здесь:
debugging - How to debug a stackoverflowexception in .NET - Stack Overflow - и ничего не нашел, но заметил, что в выводе WinDbg промелькнула ошибка c0000090. Дальнейшие исследования дали вот такую картину:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.
*** wait with pending attach
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path. *
* Use .symfix to have the debugger choose a symbol path. *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
ModLoad: 00400000 005b1000 C:\temp\test2.exe
[информация о загрузке всяких модулей]
ModLoad: 6a600000 6ab61000 C:\WINDOWS\assembly\NativeImages_v4.0.30319_32\System.Xml\850fa7110c7423c324762c1ad3130219\System.Xml.ni.dll
(560.a40): Break instruction exception - code 80000003 (first chance)
eax=7ffdd000 ebx=00000001 ecx=00000002 edx=00000003 esi=00000004 edi=00000005
eip=7c90120e esp=03b7ffcc ebp=03b7fff4 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\ntdll.dll -
ntdll!DbgBreakPoint:
7c90120e cc int 3
0:004> g
(560.e88): Unknown exception - code c0000090 (first chance)
(и так подряд 1032 строки)
1.
2.
3.
4.
5.
6.
(560.e88): Unknown exception - code c0000090 (first chance)
eax=000000c0 ebx=00170240 ecx=ffffffff edx=00000000 esi=000000fc edi=00000000
eip=7c90e514 esp=039cfc84 ebp=039cfce8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!KiFastSystemCallRet:
7c90e514 c3 ret
c0000090 - это FLT_INVALID_OPERATION, ошибка операции с плавающей точкой. И максимально сжатый дотнетовский код, приводящий к вышеописанному, выглядит вот так:
1.
Console.WriteLine(double.IsNaN(double.NaN));
причем рвется именно на вызове double.IsNan. Если обернуть это в try/catch, то результат будет нулевой - всё те же 1032 c0000090, и SOF в итоге.
Посмотрел в исходниках фреймворка, как реализован IsNan:
1.
2.
3.
4.
public unsafe static bool IsNaN(double d)
{
return (*(UInt64*)(&d) & 0x7FFFFFFFFFFFFFFFL) > 0x7FF0000000000000L;
}
- проще от этого не стало.
Если всё то же самое делать в чистом дотнетовском приложении, то проблем никаких нет. Даже если сборку загружать в отдельном домене.
Более того, если в папку с приложением положить конфиг NLog'а (библиотека использует NLog), то всё заработает нормально, причем конфиг может быть вообще пустым - т.е. длиной 0 байт. Видимо, NLog при попытке загрузки конфига, даже если он невалиден, что-то инициализирует/меняет так, что потом всё начинает работать нормально - но вот что?
