ТКС>>>Либо ты сохраняешь весь использованный стек (который иногда действительно может в 100 кило уложиться), либо у тебя есть pdb, содержащая FPO, либо у тебя в трейсе будут пропущены часть вызовов (после функций, скомпилированных без кадра стека). По другому — никак. Или я чего-то упустил?
O>>Именно так. Редко когда стек используется хотябы на половину, в противном случае скорее всего увидим глубокую рекурсию с переполнением в конце. А минидампы с рекурсией отлично жмутся зипом, хотя и без рекурсии минидампы тоже замечательно жмутся.
ТКС>Ну тут еще и ниток легко может с десяток оказаться, да и не все настолько доверяют поставщикам софта, чтобы разрешать слать хотя бы сотни килобайт непонятно чего.
Из моей практики у приложений с десятком ниток в минидампы получаются крайне мизерные в зипах. А вопрос доверия в несколько иной сфере лежит.


O>>>>В "другой" операционке нету .pdb .pdb есть только в тех операционках где есть miniDumpWriteDump
ТКС>>>Эээ — ну вот у меня скажем 32 бит виста установлена, а у клиента XP 64-бит. Как мне поможет тот факт, что у него на машине работает miniDumpWriteDump?
O>>Получите дамп и откроете его. 32хбитный windbg (адекватной свежести) прекрасно понимает дампы с 64хбитной винды.
ТКС>pdb от нужной винды оно само выкачает?
В смысле .pdb виндовые? да конечно, если настроить

Здравствуйте, ononim, Вы писали:

ТКС>>>>Либо ты сохраняешь весь использованный стек (который иногда действительно может в 100 кило уложиться), либо у тебя есть pdb, содержащая FPO, либо у тебя в трейсе будут пропущены часть вызовов (после функций, скомпилированных без кадра стека). По другому — никак. Или я чего-то упустил?
O>>>Именно так. Редко когда стек используется хотябы на половину, в противном случае скорее всего увидим глубокую рекурсию с переполнением в конце. А минидампы с рекурсией отлично жмутся зипом, хотя и без рекурсии минидампы тоже замечательно жмутся.
ТКС>>Ну тут еще и ниток легко может с десяток оказаться, да и не все настолько доверяют поставщикам софта, чтобы разрешать слать хотя бы сотни килобайт непонятно чего.
O>Из моей практики у приложений с десятком ниток в минидампы получаются крайне мизерные в зипах.

А стек при этом для всех ниток дампили при этом или только у упавшей?

O>А вопрос доверия в несколько иной сфере лежит.

Ну мы вот с таким проблемным клиентом просто показывали, что конкретно дампим. Когда имеется возможность проверить, и уверенность, что ничего существенного среди этих данных не спрятать, доверяют существенно легче.

O>>>>>В "другой" операционке нету .pdb .pdb есть только в тех операционках где есть miniDumpWriteDump
ТКС>>>>Эээ — ну вот у меня скажем 32 бит виста установлена, а у клиента XP 64-бит. Как мне поможет тот факт, что у него на машине работает miniDumpWriteDump?
O>>>Получите дамп и откроете его. 32хбитный windbg (адекватной свежести) прекрасно понимает дампы с 64хбитной винды.
ТКС>>pdb от нужной винды оно само выкачает?
O>В смысле .pdb виндовые? да конечно, если настроить

Да, виндовые .pdb. Но от другой версии винды. windbg так умеет?

ТКС>>>Ну тут еще и ниток легко может с десяток оказаться, да и не все настолько доверяют поставщикам софта, чтобы разрешать слать хотя бы сотни килобайт непонятно чего.
O>>Из моей практики у приложений с десятком ниток в минидампы получаются крайне мизерные в зипах.
ТКС>А стек при этом для всех ниток дампили при этом или только у упавшей?
У всех. Да возьмите сами попробуйте — в windbg атачитесь к процессу, потом — команда

.dump c:\dump.dmp

после чего открываем получившийся дамп , и пишем в windbg последовательно:

.symfix
.reload
~*kv ffff

и любуемся стеками. Потом смотрим размер дамп файла и много думаем на тему "нафига городить парсинг стека на клиенте". + курим хелп по miniDumpWriteDump (и почти аналогичный хелп по команде .dump в виндбг)


O>>А вопрос доверия в несколько иной сфере лежит.
ТКС>Ну мы вот с таким проблемным клиентом просто показывали, что конкретно дампим. Когда имеется возможность проверить, и уверенность, что ничего существенного среди этих данных не спрятать, доверяют существенно легче.
ну мона показать hex/ascii view

O>>>>Получите дамп и откроете его. 32хбитный windbg (адекватной свежести) прекрасно понимает дампы с 64хбитной винды.
ТКС>>>pdb от нужной винды оно само выкачает?
O>>В смысле .pdb виндовые? да конечно, если настроить
ТКС>Да, виндовые .pdb. Но от другой версии винды. windbg так умеет?
Конечно

Здравствуйте, ononim, Вы писали:

ТКС>>>>Ну тут еще и ниток легко может с десяток оказаться, да и не все настолько доверяют поставщикам софта, чтобы разрешать слать хотя бы сотни килобайт непонятно чего.
O>>>Из моей практики у приложений с десятком ниток в минидампы получаются крайне мизерные в зипах.
ТКС>>А стек при этом для всех ниток дампили при этом или только у упавшей?
O>У всех. Да возьмите сами попробуйте — в windbg атачитесь к процессу, потом — команда
O>

O>.dump c:\dump.dmp

O>после чего открываем получившийся дамп , и пишем в windbg последовательно:
O>

O>.symfix
O>.reload
O>~*kv ffff

O>и любуемся стеками. Потом смотрим размер дамп файла и много думаем на тему "нафига городить парсинг стека на клиенте". + курим хелп по miniDumpWriteDump (и почти аналогичный хелп по команде .dump в виндбг)

У меня ситуация несколько другая — все уже 10 лет назад сгорожено. Есть ряд причин чтобы переделать, и разумеется есть куча более срочных задач. Поэтому предпочитаю сначала расспросить, насколько возможно. В хелпе к MiniDumpWriteDump я не понял, что именно будет собрано об остальных нитях, если не использовать коллбэки, поэтому и уточняю.

O>>>А вопрос доверия в несколько иной сфере лежит.
ТКС>>Ну мы вот с таким проблемным клиентом просто показывали, что конкретно дампим. Когда имеется возможность проверить, и уверенность, что ничего существенного среди этих данных не спрятать, доверяют существенно легче.
O>ну мона показать hex/ascii view

Но в принципе для таких случаев можно и старым кодом пользоваться.

Здравствуйте, alfr, Вы писали:

A>Здравствуйте!

A>Подскажите, можно ли как-то запутать символы в PDB?

скорее всего нет — это закрытый формат

Здравствуйте, alfr, Вы писали:

A>Здравствуйте, catBasilio, Вы писали:

B>>Есть! Поднять у се6я symbol server и хранить пдбхи в нем.

A>Есть много противопоказаний у сервера — от стоимости трафика и скорости соединения, до корпоративных политик безопасности и запрета на доступ в Интернет

A>Но интересно, это ведь такая же штука получится, как с символами Windows, которые студия складывает в %TEMP\SymbolCache ? Тогда непонятна разница между поставкой в дистрибутиве и загрузкой по сети.
A>И даже если софт не будет сохранять их локально, всё равно есть возможность их перехватить. Если я правильно понимаю, там ведь обычные PDB пересылаются, такие же как из-под линковщика вышли.

Причем тут скорость трафика и корпоративные политики? Ты поднимаешь символ сервер у себя в офисе, на одном из компов, с доступом только во локальную сеть и настраиваешь студию на работу с символ сервером. Настраиваешь билдовый сервер (если есть) чтобы пдб-хи от каждого релизного билда он хранил на символ сервере. Далее когда тебе присылают крэшдамп, ты просто открываешь его в своей студии. Если надо дебужить у заказчика, то поднимаешь символ сервер на ноуте со студией и дебужишь.
З.Ы. Символ сервер это просто расшаренный каталог со специальной структурой, там нету ни каких постоянно работающих служб.

ТКС>У меня ситуация несколько другая — все уже 10 лет назад сгорожено. Есть ряд причин чтобы переделать, и разумеется есть куча более срочных задач. Поэтому предпочитаю сначала расспросить, насколько возможно. В хелпе к MiniDumpWriteDump я не понял, что именно будет собрано об остальных нитях, если не использовать коллбэки, поэтому и уточняю.
Бай дефолт там все правильно делается — дампятся стеки всех потоков

B>Далее когда тебе присылают крэшдамп, ты просто открываешь его в своей студии.
Оно-то всё конечно так, но проблема в том, что crashdump не подходит Не разрешат мне такое прикрутить.
Такой объем непонятных данных юзеры не отдадут — а вдруг там пороли или еще какая-то до жути личная информация.
Поэтому и ищу способы преобразовать на месте стек в нечто понимабельное

Здравствуйте, alfr, Вы писали:

B>>Далее когда тебе присылают крэшдамп, ты просто открываешь его в своей студии.
A>Оно-то всё конечно так, но проблема в том, что crashdump не подходит Не разрешат мне такое прикрутить.
A>Такой объем непонятных данных юзеры не отдадут — а вдруг там пороли или еще какая-то до жути личная информация.
A>Поэтому и ищу способы преобразовать на месте стек в нечто понимабельное

Прикрутите вместо крэшдампа BugTrap который при отсутствии PDB сгенерит вам XML с простыми hex адресами. А вы уже на своей машине с PDB увидите осмысленные имена функций в стеке вызова. Уж XML с хекс-адресами юзеры отдадут наружу?

Здравствуйте, alfr, Вы писали:

A>Может у кого-нибудь есть рецептик?
Можно сами исходники обфускатором обработать...