Настройка общего (или частного) сервера символов через http

Ответ 1

Я считаю, что ответ очень прост: "Просто поделитесь каталогом через какой-то http-путь". Согласно записи Чада Остина в разделе "Создание собственного сервера Symbol" , это будет работать.

Другими словами, каталог, который symstore.exe использует для хранения символов, когда он обслуживается как http://symbols.example.com/public_symbols/, будет использоваться в качестве цели сервера символов для средства отладки Windows.

Ответ 2

Будьте внимательны, если несколько пользователей используют Symstore.exe непосредственно в том же хранилище символов. В документах Microsoft на эту тему звучит так, как будто вы просто создаете общий ресурс и каждый обновляете программу SYMSTORE.EXE, поставляемую как часть инструментов отладки для Windows. В белых документах вам сообщалось, что это делается с помощью каждой сборки.

И он отлично работает с одиночными пользователями или при переадресации всех обновлений через одного человека, который обновляет сервер символов для команды.

К сожалению, "мелкий шрифт" в нижней части некоторых документов гласит, что только один пользователь, на котором работает symstore.exe, может одновременно обновлять общий сервер символов, не нарушая его.

(Пример: в http://msdn.microsoft.com/en-us/library/ms681417(VS.85).aspx Microsoft говорит: "Примечание. SymStore не поддерживает одновременные транзакции от нескольких пользователей. Рекомендуется, чтобы один пользователь был назначен" администратором "" хранилища символов и несут ответственность за все транзакции add и del".)

Таким образом, не существует встроенного механизма для сериализации обновлений в хранилище символов. Похоже, что несколько одновременных попыток обновления хранилища символов могут сломать хранилище символов и/или его индекс.

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

Основываясь на этих документах, я поднял эти проблемы с Microsoft в марте 2009 года; который подтвердил, что это возможная проблема. После этого мы решили внедрить службу обновления символов, которая сериализует обновления с помощью API-интерфейсов Windows Debugging Tools SDK DbgEng.DLL SymbolSrvStoreFile(), поэтому никогда не существует возможности одновременного одновременного обновления одной и той же области символов, У пользователей есть действие сборки, которое ставит их символы через службу вместо прямого обновления хранилища символов. Затем служба сериализует обновления, чтобы убедиться, что попытки одновременного обновления никогда не произойдут.

Ограниченная документация по использованию SymSrvStoreFile в то время была не совсем понятной. Я получил работу. Надеюсь, с тех пор он улучшился. если нет, то наиболее важной проблемой было то, что входной путь должен быть указан в формате, аналогичном _NT_SYMBOL_PATH. Поэтому вместо того, чтобы, например, использовать "C:\Data\MyProject\bin" в качестве входного пути, вы должны указать "srv * C:\Data\MyProject\bin".

Теперь наша служба также регистрирует обновления через базу данных. База данных служит как резервная копия хранилища символов (в случае, если она когда-либо повреждена и должна быть перестроена), а также создает точку отчетности, чтобы руководители и люди поддержки знали, кто на самом деле сохраняет свои символы, а кто нет. Мы генерируем еженедельный отчет о регистрации символов, который автоматически передается заинтересованным сторонам.

Ответ 3

Наш сервер символов (Mozilla) отлично работает, AFAICT. Мы не делаем ничего особенно сложного, мы просто помещаем файлы PDB в правильную структуру каталогов (у нас a script для этого, но вы можете использовать symstore.exe) и обслуживать его через Apache. Я считаю, что единственная особенность, которую мы имеем, - это некоторые правила перезаписи, позволяющие получать доступ к файлам нечувствительным к делу способом, потому что инструменты Microsoft действительно несовместимы в отношении имени файла/GUID.

Ответ 4

Сервер символов, обслуживаемый через HTTP, имеет ту же структуру, что и сервер символов, обслуживаемый через путь к UNC файлу, поэтому проще всего использовать symstore.exe для хранения файлов в папке где-нибудь, а затем использовать простой HTTP-сервер, который предоставляет эту папку через HTTP (даже запуск python -m SimpleHTTPServer в каталоге символов будет работать).

Небольшой getcha заключается в том, что если файл символа не существует, HTTP-сервер должен вернуть код ошибки 404 (как минимум, в Visual Studio 2013). Я столкнулся с проблемой, когда HTTP-сервер, возвращающий 403 для отсутствующих файлов, заставил Visual Studio прекратить делать запросы после первого отказавшего запроса.

symstore.exe создает несколько вспомогательных файлов и папок (папка 000Admin/, refs.ptr и files.ptr). Ни один из них не требуется для работы сервера символов.

Если вы хотите создать хранилище символов без использования symstore.exe, вы можете загрузить файлы с помощью этой структуры:

BinaryName.pdb/$BUILD_ID/BinaryName.pdb BinaryName.exe/$LINK_ID/BinaryName.exe

Где BUILD_ID - это GUID, встроенный в файл PDB и исполняемый файл, а LINK_ID - это комбинация времени сборки и размера файла в исполняемом файле. Их можно получить, прочитав вывод инструмента dump_syms.exe из библиотеки прерываний. См. http://www.chromium.org/developers/decoding-crash-dumps