Здравствуйте.

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

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

Всё это как-то не давало мне понять где же хотя бы примерно искать ошибку. Но появилась зацепка. Другой человек, который запускал дебажный билд на другом компе сказал, что у него ошибка другая:

Эта ошибка более описана в интернете, что я и изучил. При этом вдобавок известен код,где она происходит:

Этот код используется В Висте для определения наличия композитного режима в теме рабочего стола. Ошибка происходит на строке вызова импортированной функции if (FAILED(DwmIsCompositionEnabledProc(&fDwmEnabled))) 
Собственно, я делаю билд  в Win XP (русская) и у меня этот код вообще не исполняется, а вот тот человек, не знаю - в Висте или в XP и вдобавок английской.

Согласно тому, что я нашёл в инете про эту ошибку, я попробовал исправить строку объявления указателя на функцию на 


и

Однако у меня всё также Порядковый номер 13161 не найден в библиотеке DLL mfc90ud.dll.

Есть у кого-нибудь хоть какие-нибудь ещё мысли, что в этом коде можно поправить?

Мысль пока единственная - эти ошибки НИКАК друг с другом не связанны

По поводу  - у вас случайно не завалялось несколько разных mfc90ud.dll? Похоже, что библиотека импорта (с которой было слинкованно приложение) от другой версии  mfc90ud.dll

У меня ввобще два раздела. В одном стоит Win XP SP3 с MSVS 2005, а на втором та же Win XP SP3, но с MSVS 2008. Этот проект выполняется в MSVS 2008. Как мне быть уверенным, что при сборке случайно не используется mfc90ud.dll из MSVS 2005? В свойствах проекта посмотрел - везде, где стоит имя диска, оно указано верно.

Добавлено через 4 минуты и 17 секунд
поправочка: в MSVS 2005 mfc90ud.dll вообще нет. Там mfc80ud.dll.
Зато в MSVS 2008 их несколько в разных папках

dll ищется run-time по стандартным путям. Директории, которые прописанны в VS на это никак не влияют

Они все одинаковые, или разные? Попробуйте найти нужную, и положить ее рядом с exe'ником программы

Еще можно отключить в VS сборку с динамическими библиотеками (использовать статический run-time)

Этот порядковый номер используется вместо имени функции на импорте. Он должен быть прописан в def-файле библиотеки. Похоже, линкуется не та версия, которая потом используется. Можно просто поиском посмотреть это число.

Их 9 штук и они все разные


Попробовал положить рядом с exe'шником две наиболее вероятные из них: лежащие по путям D:\Program Files\Microsoft Visual Studio 9.0\VC\redist\Debug_NonRedist\x86\Microsoft.VC90.DebugMFC\mfc90ud.dll и D:\Program Files\Microsoft Visual Studio 9.0\VC\ce\dll\x86\MFC90UD.DLL. Ошибка осталась.
Остальные лежат в папках 
D:\Program Files\Microsoft Visual Studio 9.0\VC\ce\dll\mipsiv_fp\, 
D:\Program Files\Microsoft Visual Studio 9.0\VC\ce\dll\mipsiv\, 
D:\Program Files\Microsoft Visual Studio 9.0\VC\ce\dll\mipsii_fp\, 
D:\Program Files\Microsoft Visual Studio 9.0\VC\ce\dll\mipsii\, 
D:\Program Files\Microsoft Visual Studio 9.0\VC\ce\dll\armv4i\, 
D:\Program Files\Microsoft Visual Studio 9.0\VC\ce\dll\armv4\, и 
D:\Program Files\Microsoft Visual Studio 9.0\VC\ce\dll\sh4\
Так что думаю они вообще из другой оперы


Из двух проверенных dll только  в одной (самой большой, которая в папке redist) был найден ординал 13161 в таблице экспорта.  Но помещение её в папку с экзешником ошибку при рантайме не исправило.


Как это сделать? Я чё-то в свойствах проекта такой настройки не нашёл. 
Ещё момент: в проекте у меня экзкшник и dll, которая внедряется в другие процессы. Не увеличится ли значительно её размер при использованиии  статического run-time? Это нежелательно.

Это сообщение отредактировал(а) ksili - 26.6.2009, 05:52

возьмите depends.exe и натравите на свой exe шник. Посмотрите чего там выдаст.

А выдал он следующее:
во-первых, не нашёл DWMAPI.DLL, но это понятно, т.к. это вистовская библиотека, а я в XP.
во-вторых, подсвечена MFC90UD.DLL. Щёлкнул по ней, открылось второе окно, в котором показывается, что у этой длл зависимость от MSVCR90D.DLL и она не найдена.

Что ещё интересно, MFC90UD.DLL берется из папки D:\windows\winsxs\x86_microsoft.vc90.debugmfc_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_2a62a75b. чё-то я не догадывался, что они ещё могут быть в папках винды. Там оказывается таких папок куча, причём рядом с этой папкой лежит папка x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_597c3456, а в ней эта самая MFC90UD.DLL. Почему она не находится - для меня загадка.

Кстати в dll из D:\windows\winsxs\x86_microsoft.vc90.debugmfc_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_2a62a75b в экспорте не нашлось 13161.
поэтому я заменил её на ту, в которой она есть и программа запустилась в дебаге! Но все же мне кажется это неполным решением, т.к. я не понимаю из-за чего так произошло и не поломал ли я чего-нибудь другого такой заменой.

насколько я понимаю это связано с манифестом (?) посмотрите какой в манифесте указан (программой вроде reshacker можно посмотреть, или любой другой умеющей работать с ресурсами)

У меня манифест открывается практически как XML-файл. Из существенного там:

Т.е. используется версия библиотеки 9.0.21022.8. Это как раз та, в которой нет 13161. А я фактически заменил её на библиотеку версии 9.0.30729.1. 
Если я просто перепишу в манифесте версию, будет ли это корректно? Дело в том, что по пути D:\windows\winsxs\ нет папки DebugCRT с такой версией, там только с версией 9.0.21022.8. 

ты можешь и свой манифест написать при желании.
Например для common controls:
1) делаем xml файл с именем "программа.exe.manifest"

2) открываем rc файл как код и вписываем строку:

3)добавляем в проект файл "Программа.exe.manifest"....
усе...
а ну, может тебе в секции linker настройки отключить генерирование манифеста можно в случае его ручного "заведения"....