Месяца три назад я уже задавал этот вопрос по VC2005, но потом решил, что причина ошибки в пиратской копии.   
Теперь установил новую копию VC++2005. Скачана она с сайта DreamSpark, по описанию в нём фирма Мicrosoft позволяет приобретать лицензионный софт.
Запустил  большую программу с графическими файлами, меню, диалогами, MDI и т.д. , всё отработало без единой ошибки. Но!
Запускаю программу в режиме Debug | Win32 и в окне Output от операторов TRACE() нет ни одного сообщения. Причём системные сообщенмя есть и в Output-Debug и в Output- Build .
Примерно такие:   'Prov.exe': Loaded 'C:\Program Files\Portrait Displays\Pivot Software\Winphook.dll', Binary was not built with debug information.      // почему not build ?
                               The program '[1688] Prov.exe: Native' has exited with code 0 (0x0).

Взял простейшие примеры из MSDN 2005 ,  в ProvView.cpp включил  #include "atlbase.h"  и в OnDraw включил TRACE( ):
 Оператор TextOutW () сообщение на экран вывел, но ни одного сообщения в окне Output не появилось.  В чём дело?
Поскольку я не получил ни одного ответа в других форумах, то решил высказать предположения :
1. Причина в кодировке Unicod и нужно по другому оформлять TRACE.  (До этого я работал в 6-ой студии).
2. Может быть причина в Windows XP Professional, версия 2002, Service Pack-2 .
3. Может быть кроме окон Output-Debug и Output-Build есть ещё третье окно для отладочных сообщений ??

Все 3 твоих предположения неверны. TRACE не имеет никакого отношения к TextOut, и делать какие-то выводы на основе того, что кто-то из них работает, а кто-то нет - бессмысленно. Окно Output это и есть окно, куда выводтся трассировочные сообщения.
То, что ты называешь системными сообщениями - это работа OutputDebugString. TRACE'ы в итоге тоже вызывают ровно эту функцию. ATLTRACE - тоже самое, что TRACE. 

Управляется это дело, во-первых, макро-флагом _DEBUG (кстати проверь, что он у тебя установлен: debug-сборка сама по себе еще не означает, что он стоит. Т.е. по умолчанию среда действительно задает его при создании проекта, но сдуру ума его могли и прибить). Кроме того, есть еще специальные флаги внутри самого TRACE. Т.е. убедись сначала, что _DEBUG у тебя установлен - грубо говоря, что ты можешь зайти отладчиком внутрь TRACE, а дальше пройди по шагам.

      В ProvView.cpp cтоят операторы :
На всякий случай закомментировал их и поставил один : #define _DEBUG    Транслятор выдал   ' _DEBUG'  macro  redefinition
Т.е. _DEBUG переопределён, значит уже есть. Выводов от TRACE по прежнему нет. По каким шагам идти дальше не знаю. Объясни, пожалуйста, подробнее.

Ставь точку прерывания на любой свой TRACE и иди внутрь по шагам.
Твоя главная задача - дошагать до функции с именем AtlTraceVA и посмотреть, что там внутри. А внутри-таки должен быть вызов OutputDebugString. Впрочем, возможет и вариант, когда будет установлена и вызвана pfnCrtDbgReport, но там в конце концов тоже дело сводиться к OutputDebugString. Ты должен установить, какие-такие условия тебя туда не пускают. Или даже не пускают дойтить до  AtlTraceVA.
Все это дело происходит у меня в 2003; не думаю, что в 2005 все сильно изменилось, но даже если изменилось - смысл должен остаться: в конце должна быть OutputDebugString.

       Earnest, макрос TRACE при пошаговом просмотре оказался огромной задачей, примерно 30 методов с уровнем вложения до 6 . ( Потому что это API ).  Дошёл, наконец до такого места:
  Причём выполняется условие if( != NULL)=TRUE, else не выполняется.
   Я убрал условия и оставил безусловный   OutputDebugStringA(szBuf);   Такое нахальство VC++  не понравилось. Сообщения от TRACE() всё равно нет, а при следующем пошаговом просмотре стал вылетать в
 недействительную область.  Пробовал поставить   OutputDebugStringA(szBuf);  прямо в OnDraw , но результат тот же, что и TRACE.
 И такой вопрос: выходит всё-таки, что "лицензионный" софт с пиратскими наклонностями? Что посоветуешь делать.

Подумаешь, у меня на это минуты 3 ушло, пока тебе пост писала прошлый раз. У меня тоже идет в if, т.е. вызывается pfnCrtDebugReport; вот там и происходит в конце концов вызов OutputDebugString.
Кстати, с помощью CrtDebug-функций можно свой обработчик туда вставить. Вот и посмотри для начала, куда ведет тебя pfnCrtDebugReport. Возникает такое ощущение, что кто-то перехватывает этот вызов и забирает инфу себе... 
У тебя ничего сверху не стоит?

     Сейчас и у меня быстрее получается, а первый раз повозился.
        
  Не понял, где сверху?
 Просмотрел я всю цепочку методов, что-то понял, а что-то нет, ошибку не нашёл. Но вопрос в другом. Я в первом посте привёл пример, четыре строки кодов. Три строки я убираю и остаётся
 безусловный оператор OutputDebugStringA, который мне нужен. Что я сделал неправильно? Но после этого Debuger при пошаговой отладке ( когда вхожу в метод AtlTraceVA ) даёт сообщение,
 что невозможно представить коды в символьном виде и переходит на Assembler. И я уже не могу посмотреть, как работает моё исправление. Подозрение такое, что сбивается адресация.
 Так может быть нужно указать в проекте, что библиотечный файл  atldebugapi.cpp необходимо включить в проект для трансляции и сборки? Или это происходит автоматически?
  Тогда не знаю, почему не действует моё исправление.  

"Сверху" - имелось в виду какое- приложение, плагин или что-то вроде, перехватывающее трассировочный вывод.

Чтобы подействовало твое исправление, нужно перестроить библиотеки, а ты ведь этого не делал, а просто поправил исходный код; поэтому тебе и говорят, что исходный код не соответствует бинарнику.
Но я и не рекомендую тебе перестраивать стандартные библиотеки. Во-первых, геморройное это дело, во-вторых - оснований недостаточно, чтобы в это лезть. Ты ведь дошел до if (pfnCrtDbgReport != NULL), вот и войди внутрь pfnDebugReport, посмотри куда указатель ведет. У меня, например, pfnDebugReport == _CrtDbgReport (функция из CRT-библиотеки). А устанавливается это дело, во-первых, в atltrace.h при инициализации вспомогательного классика CTrace. А еще есть интересный код в CAtlTraceModule::CrtDbgReport. Может, у тебя используется ATL и кто-то переустанавливает эту функцию?

     Для проверки Debug-а я создал проект Prov, в котором всего один оператор: в OnDraw стоит TRACE("Вывод TRAC-a\n");  Поэтому у меня и сверху ничего нет, и ATL я не использую.
 Может быть ATL в 8-ой студии автоматически подключается, этого я пока не знаю. Далее: и в CAtlTraceModule и в CTrace, на мой взгляд, подключаются _СrtDbgReport.
 Привожу их коды, вроде всё в порядке. 
Вообще-то я Win API не знаю, я от С++ сразу перешёл к MFC, поэтому могу и не увидеть ошибку.

Я имею в виду какой-нибудь плагин, расширение среды - типа Visual Assist, а не твои программы.


Да, конечно, это нормально. Вопрос в другом: когда ты доходишь до ветки fnCrtDbgReport, чему равен этот указатель? Ты заходишь именно в _СrtDbgReport или в другую функцию? Третий раз спрашиваю, а ты молчишь как партизан... И если в CrtDebugReport, то доходишь ли до OutputDebugString?

      Плагинов и прочего у меня нет. Посмотрел содержимое  pfnCrtDbgReport , там ещё вызываются методы,  обозначу их коротко.
           _CRTIMP int __cdecl  _CrtDbgReportT(...) -->  --INLINE INT --cdecl -CrtDbgReportTV(...) --> _CRTIMP int __cdecl  _VCrtDbgReportA(...) --> _VCrtDbgReportT(...);
 OutputDebugString не вызывается, хотя этих операторов там много в разных вариантах, но "стрелка" через них перепрыгнула.

Ок, давай сравним \ проследим:
Внутри _CrtDbgReport сначала стоит большой if для обработки ASSERT, мы его проскакиваем, потому что у нас не ассерт.
Дальше, вот в этом коде:

_pfnReportHook стоит, но возвращает false и мы идем дальше. Потом еще один if, который мы проскакиваем и, наконец вуаля:

Вот сюда мы заходим. Так трейс отрабатывает у меня. Если у тебя не заходит в этот if, то видимо дело во флагах _CrtDbgMode (кстати, nRptType у меня 0), и надо искать, какая св.. их портит...

      У меня всё точно так же. nRptType тоже равно 0. Когда я захожу в OutputDebugStringA( szOutMessage), там такие коды на Ассемблере:
    {
     адрес   lea      eax,[ebp-3028h]
     .........    push   eax
     .........    call     dword  ptr[ __imp__OutputDebugStringA@4(102CC038h)]
    }
 
  Значит это до того, как ты исправила? Что теперь ?

Я ничего не исправляла, у меня и так все работает...
Я правильно понимаю, что в OutputDebugString ты заходишь, и в передаваемом аргументе-строке все нормально, но в панель Output ничего не пишется? А тем не менее, какой-то вывод при загрузке приложения в Output есть? Ну ничего себе!
Тогда даже не знаю, что посоветовать... Может, попробуешь среду переставить? Если хочешь дальше разбираться в этом деле, сходи на сайт Руссиновича www.sysinetrnals.com, там есть утилитка DebugView. Во-первых, она умеет хвать вывод OutputDebugString к себе в окно (очень удобно для отладки релиза, который не работате только без среды), но суть не в этом: вроде я когда-то у него видела объяснение принципов как оно там работает и чуть ли не код утилиты. Может, это поможет разобраться.

   
 А вот я не знаю нормально ли всё у меня в аргументе строке. Вот стоит "маркер" Debuger-a на операторе call     dword  ptr[ __imp__OutputDebugStringA@4(102CC038h)]  , и я нажимаю Step Into.
 Мне кажется я должен перейти к области памяти описывающей OutputDebugStringA, ведь это подпрограмма, а не один оператор. Но у меня при нажатии Step Into "маркер" проскакивает
 дальше и выходит из OutputDebugStringA.
   
 Хочу просто уточнить, "переставить"-заново инсталлировать Windows XP ?