c # 4.7.2 сбой в clr.dll при отладке и запуске с нативного - PullRequest
Новая
       25

c # 4.7.2 сбой в clr.dll при отладке и запуске с нативного

0 голосов
/ 06 июля 2018

У меня есть проект в смешанном режиме, где я запускаю собственный код на c ++, загружаю и использую несколько сборок c # 4.7.2. Долгое время все работало нормально, но я наткнулся на одну проблему. C # только модульные тесты работают нормально. Только модульные тесты C ++, вызывающие управляемую работу, работают нормально, когда отладка в смешанном режиме отключена. Когда я включаю отладку в смешанном режиме, я могу делать сеанс отладки, начиная с нативного управления, но у меня происходит сбой clr.dll с нарушением прав доступа по адресу 0, когда я вхожу в какой-то определенный фрагмент кода:

Исключение, выброшенное в 0x00007FFAF53A2774 (clr.dll) в server_unittests.exe: 0xC0000005: место чтения нарушения прав доступа 0x0000000000000000

Это является детерминированным и происходит при вызове базового конструктора из производного класса.

Код работает, нет утечек или чего-либо и может быть отлажен, но умирает, когда сеанс запускается из-под неуправляемого. Это выглядит примерно так: 

public DerivedData(uint customerId, bool load) : public BaseData(int customerId, string idName, string table, HashSet<(string colName, Constants.DbTypes colType, bool client, int verbosity)> vars, BaseData initialValues = null)

и вылетает в тот момент, когда он должен войти в код конструктора базового класса.

Для моста человек-не-человек я использую проект 3F / DllExport. У меня последняя версия против 2017 года.

Пожалуйста, помогите мне найти шаблон, который приводит к сбою, или укажите мне конфигурацию GUI, которая заставит его исчезнуть:)

Он начал выдавать другую ошибку после некоторых опций:

Помощник по управляемой отладке «FatalExecutionEngineError» обнаружил проблему в «server_unittests.exe». Дополнительная информация: во время выполнения произошла фатальная ошибка. Адрес ошибки был 0xf53a2774 в потоке 0x1a6c. Код ошибки 0xc0000005. Эта ошибка может быть ошибкой в ​​CLR или в небезопасных или не поддающихся проверке частях пользовательского кода. Распространенными источниками этой ошибки являются ошибки пользовательского маршалинга для COM-взаимодействия или PInvoke, которые могут повредить стек.

...