Ошибки Delphi на сервере удаленных рабочих столов

Question

Существуют ли какие-либо инструменты ведения журнала / трассировки, которые я могу включить для EXE-файлов на базе Delphi, не имея доступа к коду Delphi, только к скомпилированным EXE-файлам и связанным DLL-файлам?

Вот почему мне это нужно: некоторые пользователи нашего сервера удаленных рабочих столов Windows 2012 (ранее называвшегося Terminal Server) периодически сталкиваются с ошибками внешних исключений C0000006, но только для сторонних приложений на основе Delphi, доступ к которым осуществляется из общего расположения в сети (т.е. не локально для сервера RDS). Локальные пользователи ПК в офисе, имеющие одинаковый доступ к одним и тем же файлам, не имеют проблемы. Пользователи RDS не испытывают проблемы, если EXE-файлы копируются на сервер RDS; однако это всего лишь тест, а не решение, из-за некоторых ограничений приложения.

Вот что важно: это происходит только с клиентами RDS, работающими на Mac (около шести пользователей), а не с клиентами RDS Windows (около 15 пользователей).

Я уже разместил подробный, но пока не отвеченный вопрос на форуме сервера терминалов MS. Мои исследования показывают, что в этом поведении нет ничего нового.

1. В Windows 2000 было исправление проблемы с тем же симптомом, который был связан с путаницей Windows в отношении того, в каком сеансе клиента была открыта конкретная программа.
2. Даже недавно, в Windows 2008, существуют специфичные для Delphi проблемы с сетевым доступом в RDS, связанные с тем, как он загружает части EXE /DLL по требованию, а не один раз при открытии приложения. Я предполагаю, что, хотя симптомы одинаковы, первопричина должна быть несколько иной.

Поэтому, ожидая прогноза сторонних разработчиков, я пытаюсь выяснить, можно ли каким-либо образом настроить трассировку активности, специфичную для Delphi или, возможно, даже для сети, которая может сказать мне моменты, когда конкретный сеанс обращается к конкретному сетевому файлу. По крайней мере, это могло бы помочь мне определить события, которые связаны с моментами, когда пользователи испытывают ошибки.

Answer 1

Вам не нужно регистрировать какие-либо программы, потому что ошибка более фундаментальная и не связана с каким-либо языком программирования. Это собственный код ошибки API, значение NTSTATUS, в частности STATUS_IN_PAGE_ERROR,

Это ошибки низкого уровня, указывающие на фундаментальную проблему с системой виртуальной памяти. Страницы виртуальной памяти могут храниться на диске, когда физическая память недоступна. Для исполняемых модулей, если система знает, что страница хранится на диске, и эту страницу можно удалить, система сделает это, зная, что эту страницу можно будет извлечь позже. Иногда страница даже не загружалась в память. Исполняемые модули выгружаются по требованию.

STATUS_IN_PAGE_ERROR ошибка означает, что системе виртуальной памяти не удалось перенести страницу в память. Это редко для сбоя, когда исполняемый файл является локальным. Реже, когда исполняемый файл удален.

Стандартный способ справиться с этим - добавить IMAGE_FILE_NET_RUN_FROM_SWAP Флаг PE для любых модулей, которые живут удаленно. Затем происходит то, что загрузчик сначала копирует весь файл для подкачки, хранится локально, а затем загружает оттуда исполняемый файл. Поскольку файл подкачки является локальным, менее важно иметь страницу с ошибками. Вы можете применить флаг PE самостоятельно, чтобы испытать это. Вероятно, это сработает, потому что вы уже прокомментировали, что проблема решается, когда файлы копируются в локальный режим.

Вполне вероятно, что существуют общесистемные политики, позволяющие сделать это для всех удаленных исполняемых файлов.