MuForum, максимальный размер стека, не меняется если его не менять   а задается он при компиляции программы
а чтобы определить размеры стеков каждого потока, надо очевидно их перечислить (Thread32First/Thread32Next)
можно получить esp из контекста каждого потока: OpenThread/GetThreadContext
но где брать границы их стеков я не знаю. Разве что выполнять свой код с контексте каждого потока чтобы получить TEB, но наверное список TEB можно получить както еще.

на самом деле все просто:
NtQueryInformationThread с классом ThreadBasicInformation позволяет получить структуру THREAD_BASIC_INFORMATION в которой есть указатель на TEB, TebBaseAddress, откуда можно получить границы стека (база и максимальный размер).
Тогда надо посчитать разницу между вершиной стека (база+макс_размер) и esp (который можно получить из контекста потока), это будет текущий размер всех данных в стеке.
Однако для определения размера памяти которая выделена под стек, надо перебрать страницы стека, начиная с его базы, до первой страницы с флагом COMMITED.

тогда уж лучше всего использовать CRT и получить базу стека так, как это делает crtexe.c:

это вершина стека

код более-менее переносим, и есть некоторая гарантия, что поддержка CRT будет периодически делать апгрейд для NtCurrentTeb

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

Так что есть вариант, очень простой, а именно ставим хук(лучше не виндовский) на создание потока, получаем максимальный размер стека. 
Ну а вот что на счет статистики, то сдесь вопрос сложнее все зависит от конкретики.

1) Если требуется только текущее состояние потока то читай GoldFinch

2) Если требуется полное состояние(то и есть история) я имею ввиду пик стека, средние значения и так далее, то это сложнея
    - CreateProcess(с параметром DEBUG)
   - Цикл дебагера 
   -  Дизассемблер длин()
   - Ставим бряки на calls(так как раскрутка стека почти всегда в начали функции)
   - И бряку на создания потоков(хоть и приходит сообщения(в цикле дебагинга), но там кажется нельзя получить стек потока )

Вообщем все довольно просто......

DrHex, перечитай тему, т.к. мы уже давно выяснили, что сделать это можно

смотря что понимать под "концом стека", верхний или нижний?
вверху стоит сторож в виде одной страницы, а внизу - стек потому и распределется сразу, чтобы внизу были неиспользуемые приложением страницы,
хотя, учитывая, что куча идет первой, внизу таки есть критическая зона, только при чем тут определение размеров стека?

а в остальном, я так и не понял, что ты хотел сказать,
т.к. язык которым ты пользуешься к программному не относится,
а по-человечески у тебя сформулировать ни мысль ни план не получилось,
и при чем тут дебагер, или ты предлагаешь писать отладчик чтобы собирать статистику по стеку?

скорее всего сторож стоит таки внизу (не дотягивает он вверху на страницу)

GremlinProg  что не понятного???




Можно взять готовый отладчик....



GremlinProg  - и это  отладчик?????
 - Без пользовательского интерфейса(точнее вообще без управлением отладчиком)
 - Без возможности трасировки(пошаговой и так далее).
 - Без загрузки символом
 - Без полного дизассембилирования
 - и еще пунктов 100-200.

И так это часть отладчика.

А какой другой вариант собирать полную статистику??????

Отладочное апи требуется для того что бы была возможность собирать инфу. (специально для GremlinProg  такая информация как раскрутка стека, то и есть вычисление пика, среднее значения, какие потоки были запущенны и с каким размером стека)

<...скрыто...>

M GremlinProg

обсуждать лично меня можно в книге жалоб, а здесь не стоит лепить этот импровизированный сломаный телефон, DrHex нарушил правила дважды и это было не здесь

Это сообщение отредактировал(а) GremlinProg - 28.8.2009, 18:15