Какие файлы можно удалить из папки Debug?
Можно ли их удалить при переносе папки для дальнейшего использования программы (т.е. нужны ли они для работы програмы)?
Для чего они?
- Вопрос задан более трёх лет назад
- 4130 просмотров
- Вконтакте
- Вконтакте
Во-первых для дальнейшего использования программы вам нужно скомпилировать ее в конфигурации Release. Какие дефолтовые настройки стоят для каждой из конфигураций можно посмотреть в файле проекта.
*.pdb это не странные файлы, а отладочная информация, если я не ошибаюсь, в Release конфигурации они по-дефолту не создаются. Если все таки они есть — можете спокойно их удалять.
.vshost.exe.* — это файлы помощника студийного дебаггера. Для самостоятельной работы программы они также не нужны.
.exe.config — потребность в этом файле зависит от того, что в нем написано. Если не понимаете, что там — лучше оставить его и поставлять с программой (там, например, могут быть редиректы версий сборок).
*.xml — если это не ваши xml-ки, то обычно это автосгенеренная документация. Если у вас приложение, а не библиотека, можете убрать их из поставки.
Насчет остального должны знать сами. А вообще, изучайте инструмент, которым пользуетесь, если уже дошли до этапа поставки приложения (если конечно у вас не лабораторка там 🙂 )
- Вконтакте
Не нужны.
Вы собрали debug версию программы, которая содержит множество дополнительной информации для ее отладки.
Переключите компиляцию в режим release и лишних файлов не будет, и конечный исполняемый файл будет меньше по размеру и работать быстрее.
Lpc debug что это
Один из вариантов диагностики материнских плат компьютеров — использование POSTкарт… Не буду описывать историю развития средств диагностики и их современные разновидности, рассмотрим частный случай — использование LPC. Интерфейс LPC (Low pin count) — использует, как видно из названия, уменьшенное количество линий для передачи информации. Для DEBUG-целей используется по-сути 7 линий: D0-D3, Frame, RST, CLK.
Некоторые производители матплат выводят эти линии (плюс землю и питание) на отдельный разъем (часто DEBUG-разъем есть в ноутбуках ASUS, Samsung). Некоторые выводят на неиспользуемые пины разъемов mini-pci, некоторые не выводят никуда — в таком случае для получения отладочной информации приходится припаивать эти самые 7 (с общим и питанием — 9) линий непосредственно к выводам мультиконтроллера (задача весьма непростая, требующая аккуратности), либо флешки БИОСа (да, были флешки которые подключались к мультиконтроллеру тоже при помощи LPC-интерфейса, т.е. он не только диагностический, а вполне себе полноценный интерфейс обмена данными). К флешке припаяться было легче, но такие флешки уже почти не встречаются, а вытеснены SPI-собратьями.
Я упоминал уже что иногда все нужные сигналы присутствуют на mini-pci разъеме — меняем вай-фай платку на post-карту и всё видим.. Но бывают еще варианты. Один из которых, достаточно простой, но судя по вопросам на форумах почему-то не всем очевидный, рассмотрю здесь подробно и с картинками.
В качестве примера подвернулся Lenovo G555, платформа COMPAL LA-5972P. Схема без труда гуглится. Смотрим на стр. 31 и видим (выделил куда именно смотреть):
Итого как бы всё есть — D0-D3 на выводах 16, 14, 12, 10; frame — 8; RST — 17; CLC — 19.
Вставляем карту, включаем питание — и ничего: ни клок не мигает на карте, ни коды не идут…. Смотрим на ту же страницу схемы но в другое место:
Значек «@» возле элемента на схемах обычно обозначает что элемент на плате не установлен… То есть в схеме есть, а на плате нет 🙂 Смотрим на плату — и «таки да», напротив контактов 8, 10, 12, 14, 16 видим пустые места под резисторы…
Берем указанные на схеме резисторы с нулевым сопротивлением с 5%-й точностью, и впаиваем. Если таких резисторов у вас нет (как и у меня), то можно обойтись «соплями» припоя, либо тонкими проводочками. Должно получиться примерно так:
Возле 17-го контакта (там у нас сигнал RESET) тоже видим площадки, поступаем аналогично:
А вот с 19-м немного засада…. Площадок возле разъема нет, а если посмотреть на схему — то резистора R973 нам тоже не хватает чтобы увидеть сигнал наличия тактовой частоты на пост-карте…. Не буду томить — площадка под него находится на другой стороне платы, найдена мультиметром.
Впаиваем резитор-перемычку, вставляем пост-карту в слот от вайфая, нажимаем кнопку включения питания — и всё работает: видим POST-код 76, обозначающий в данном случае отсутствие оперативной памяти (не вставил):
Как бы и всё.. Ну, если уже рассказывать о конкретно этом случае, то кодов сначала у меня не было — был мертв 216-0752001. Поменял его на 216-0752003, коды пошли, всё заработало, клиент счастлив.
PS: Еще маленький «хинт», очевидный для тех кто смотрит схемы, но к сожалению это делают не все… Чтобы нажать на этой плате кнопку включения — необязательно подключать панель с кнопкой, что есть не очень удобно в разобранном состоянии… На плате такие вот площадки (J5):
Просто коротим их подручным токопроводящим предметом — и плата должна стартануть. Нарисовано это на 35-й странице схемы. В принципе в этой статье всё взято из схемы — как говорит детский стишок: «как хорошо уметь читать…».
POST карты не первое десятилетие используются для диагностики «железных» неисправностей компьютеров и материнских плат всевозможных форм-факторов. На данный момент этих карт создано очень много, практически для всех возможных ситуаций. Статья рассказывает о том, что такое POST карты и для чего их используют, как они работают, какие бывают и чем друг от друга отличаются.
После нажатия кнопки включения компьютера BIOS проводит поэтапную проверку и инициализацию всех элементов аппаратной части компьютера. Называется этот процесс: POST (англ. Power-On Self-Test – самотестирование после включения). Не только компьютеры, но и большинство современных электронных устройств имеют схожие системы.
BIOS сообщает статус (или результат) прохождения POST несколькими способами:
1. Вывод сообщений на экран. Самый дружественный и информативный способ. По сути, доступен только после успешного или почти успешного прохождения самотестирования. Отсутствие какой-либо информации на экране говорит о серьезных неисправностях базовых компонентов (материнская плата, процессор, память, видеоадаптер и т.д.). Диагностика ошибок возможна в основном только для периферийных устройств (накопители, клава и др.).
2. Звуковые сигналы. Наверное, все слышали короткий «биип» при включении компьютера – в большинстве BIOS это означает прохождение теста без ошибок и готовность к загрузке ОС. Другие варианты сигналов могут говорить об определенных проблемах с железом. Эти коды «азбуки Морзе» различаются у разных производителей и даже разных версий BIOS. Найти их обычно можно в книжке к материнке или соответствующих онлайн справочниках.
3. POST коды. В ходе каждого этапа процесса самотестирования BIOS отправляет текущий код на порт 80h (иногда 81h или другие), и если возникает ошибка, там остается или код операции, на которой произошел сбой, или код последней успешной операции. Считав этот код, можно определить на каком этапе произошла ошибка, и что могло ее вызвать. Это единственный из всех перечисленных способов, который позволяет идентифицировать проблемы на материнской плате, которая не подает видимых признаков жизни. По этой причине, он обычно используется для диагностики и ремонта непосредственно материнских плат.
Если первые два способа диагностики не требуют специального оборудования, разве что монитор и подключенный к материнской плате динамик (бывает, что его там нет), то для третьего способа вам понадобиться собственно POST карта.
Основная задача любой POST карты – это считать и отобразить текущий POST код. Считать его можно несколькими способами: по шинам ISA, PCI, LPC или через LPT порт. Есть и другие, более экзотические варианты (о них чуть позже). Кроме, собственно, отображения кода, хорошие POST карты имеют дополнительные диагностические возможности (индикаторы, режимы тестирования, встречаются даже со встроенным видеоадаптером).
Некоторые материнские платы (обычно Premium сегмента) имеют встроенный индикатор POST кодов.
Первыми POST картами были карты для шины ISA, существовавшей с 1981 по 199х годы. Используется она даже сейчас (хоть и весьма редко), в основном в промышленном и военном секторе – там, где осталось оборудование для этой шины.
Следующей массовой компьютерной шиной стала PCI. Сейчас это самая распространенная шина для настольных компьютеров. Естественно, для нее есть и POST карты всех возможных форм, размеров и функций. Самую простейшую, с обычным сегментным индикатором, можно купить за 2-3 бакса на любом Ebay, Ali и им подобным.
В принципе, такая карта со своей базовой задачей вполне справляется – POST код вы узнаете. Но для профессиональной работы этого мало. Полезно иметь индикаторы основных напряжений (обычно: +5, +3.3, +12, -12, +3.3 Standby) и индикаторы сигналов шины (из самых базовых: CLK, RST#, FRAME#, IRDY#). Важно иметь возможность переключения порта, на котором карта «слушает» коды POST (не только стандартный 80h). Бывают и другие «фишки», отсюда и такой «навороченный» вид у продвинутых карточек.
Еще один удобный вариант – это выносной индикатор. Он позволяет со всеми удобствами производить диагностику материнских плат, не вынимая их из системника. С одной стороны, если дело дошло до POST карты, то скорей всего материнку все же придется извлечь для ремонта, но с другой стороны – не всегда, да и POST карты просто удобный способ общей диагностики. На фото Sintech ST8679, китайская карточка с выносным многострочным LCD дисплеем.
Существуют POST карты для LPT порта – довольно простой и удобный способ диагностики для любого компьютера или ноутбука, имеющего этот самый LPT порт. Из-за технических особенностей, они не имеют возможностей, присущих картам для PCI, но это компенсируется простотой и доступностью. Требуют питание по USB (для этого и наличие порта на плате).
Однако LPT изживает свой век, и на современных компьютерах их уже почти не встретишь, соответственно, доживают свои дни и эти карты.
Служивший нам верой и правдой много лет PCI, постепенно вытесняет более современная PCI-Express. Немалое количество современных материнских плат вообще не имеют слота PCI (хотя и могут иметь саму шину). Но с PCI-E не все так просто. Во-первых, сама диагностика с помощью PCI-E на данный момент вещь мутная, хотя бы, из-за отсутствия адекватной информации. Во-вторых, с PCI-E все зависит от конкретного изготовителя – нет гарантии, что коды будут выводиться; если и выводятся, то нет гарантии, что по стандартному порту и в стандартном виде.
Одним из самых перспективных способов диагностики на сегодняшний день является USB. И главная тому причина – повсеместная распространенность этого интерфейса. Как мы уже выяснили, отсутствие того или иного разъема на материнской плате может стать преткновением для диагностики. И эту проблему как раз решает USB – парочку портов имеют буквально все компьютеры и ноутбуки, выпущенные за последние 15 лет.
Для такой диагностики необходимо наличие в системе USB Debug Port – это своего рода расширение USB, позволяющее передавать диагностическую информацию. В USB 3.0 реализация Debug Port получилась сподручней (подробней о Debug Port можно прочитать по ссылке). Кроме передачи POST кодов, Debug Port позволяет производить полноценную отладку кода BIOS и UEFI.
Было даже выпущено несколько устройств разными компаниями. NET20DC от Ajays (компания почти тут же обанкротилась, так как поставщики отказались поставлять им компоненты для сборки девайса). Insyde H2O DDT от Insyde Software (выпущен, вроде, в 2008 году, но информация об этом девайсе канула в лету даже на официальном сайте). Оба этих устройства скорее отладчики, хотя и имеют возможность захвата POST кодов.
С ноутбуками все немного сложней. Наиболее распространенные разъемы, которые можно использовать для диагностики – это mini PCI или Mini PCI-E (у более современных).
Опять же, есть вариант использования шины LPC. На материнских платах порта для подключения к этой шине вполне может не быть, поэтому придется напрямую подпаиваться к плате или контролеру.
Отдельные производители имеют свои способы диагностики, тут уж действительно «кто во что горазд». К сожалению, эта информация обычно является достоянием лишь производителя и его внутренних сервисных центров, поэтому все существующие варианты POST карт в общем доступе вряд ли найдутся.
Такое вот у POST карт интересное прошлое и насыщенное настоящее. Что их ждет в будущем? Поживем – увидим. Но реалии таковы, что в нынешнюю эпоху потребительства от девайсов зачастую избавляются раньше, чем они успевают сломаться. А если и ломаются, то оказываются в сервисных мастерских производителя, где уж явно должно быть подходящее диагностическое оборудование.
Can be found on some new ECS motherboards, such as ECS H61H-G11, intended for POST card connection. Uses mini-IDC connector with 2 mm pitch.
Debug — что это? Описание инструмента
Debug — что это? Debug, или отладка. в компьютерном программировании и разработке, — это многоэтапный процесс, который включает определение проблемы, выявление ее источника, а затем исправление сбоя или выбор способа дальнейшей работы. Последним шагом отладки является проверка корректного исправления.
Введение
Разработка программных продуктов проходит тщательное тестирование, обновление, устранение неполадок и обслуживание. В процессе отладки готовые программные решения регулярно компилируются и выполняются для выявления и устранения проблем. Крупные программы, содержащие миллионы строк исходного кода, делятся на небольшие компоненты. Для эффективности каждый компонент сначала отлаживается отдельно, а затем — в совокупности в рамках программного продукта.
Debug — что это и как работает? Тактика может включать интерактивную отладку, анализ потока управления, модульное и интеграционное тестирование, анализ файлов журналов, мониторинг на уровне приложений или системы, дампы памяти и профилирование.
Debug — что это? Описание процесса
Debug — это штатный процесс поиска и удаления сбоев, ошибок или аномалий компьютерной программы, которые программисты обрабатывают с помощью инструментов отладки. Отладка проверяет, обнаруживает и исправляет ошибки, чтобы обеспечить правильную работу приложения в соответствии с установленными спецификациями.
В разработке программного обеспечения отладка включает в себя поиск и исправление ошибок кода в компьютерной программе. Debug является важным этапом процесса тестирования программного обеспечения и неотъемлемой частью всего жизненного цикла разработки ПО. Процесс отладки начинается, как только код записывается, и продолжается на последующих этапах, поскольку код объединяется с другими модулями программирования для формирования программного продукта. В большой программе, имеющей тысячи строк кода, процесс отладки можно упростить, используя такие стратегии, как модульные тесты, обзоры кода и парное программирование.
Debug в контексте MS-DOS
В MS-DOS Debug — что это? Это команда, которая позволяет программистам исследовать и изменять источники содержимого памяти, которые происходят в операционной системе. Методика предоставления инструкций по компьютерным задачам через интерфейс командной строки изначально использовалась в средах MS-DOS для перевода кода ассемблера в рабочий код и машинного языка в исполняемые (debug.exe) файлы.
Debug позволяет разработчикам просматривать содержимое памяти, вносить изменения, а затем выполнять COM, .exe и другие типы файлов.
История
Microsoft впервые представила команду debug в MS-DOS 1.0 в качестве метода тестирования программ. Была добавлена дополнительная функциональность — инструмент ориентировался на различные операционные задачи, такие как отображение содержимого части памяти, ввод данных по указанному адресу, запуск исполняемых файлов памяти, шестнадцатеричная арифметика и манипуляция регистрационной памятью.
Важный этап обнаружения ошибок
После выявления программного сбоя необходимо найти ошибку в коде (Debug error). На этом этапе полезно просмотреть ведение журнала кода и использовать автономный инструмент отладчика или компонент отладки интегрированной среды разработки (IDE). Изначально обнаруживаются и фиксируются ошибки в наиболее популярных функциях. В некоторых случаях модуль, представляющий проблему, очевиден, а сама строка кода — нет. В этом случае модульные тесты, такие как JUnit и xUnit, которые позволяют программисту запускать определенную функцию с конкретными входами, могут быть полезны при отладке.
Процесс отладки
Стандартная практика состоит в том, чтобы настроить и запустить программу до точки остановки, при которой прекращается выполнение программы. Компонент отладки IDE обычно предоставляет программисту возможность просматривать память и переменные, запускать программу до следующей финальной точки, выполнять только следующую строку кода и в некоторых случаях изменять значение переменных или содержимое строки кода, которая должна быть выполнена.
Общие инструменты отладки
Анализаторы исходного кода, которые включают в себя безопасность, общие ошибки кода и анализаторы сложности, также могут быть полезны при отладке. Анализатор сложности способен найти модули, которые настолько сложны, что их трудно понять и проверить. Некоторые инструменты могут фактически анализировать пробный прогон, чтобы увидеть, какие строки кода не выполнялись. Это может существенно помочь в отладке. Другие инструменты для отладки включают расширенное протоколирование и симуляторы, которые позволяют профессиональному программисту моделировать поведение программы на оборудовании пользователя.
Поиск и удаление ошибок программного обеспечения
Некоторые инструменты, особенно инструменты с открытым исходным кодом и языки сценариев, не запускаются в среде IDE и требуют ручного подхода к отладке. Такие методы включают в себя сброс значений в журнал, расширенные «печатные» заявления, добавленные во время выполнения кода или жестко закодированные debug-команды (например, wait), которые имитируют точку остановки, ожидая ввода клавиатуры в определенное время.
Debug Dump Files — можно ли удалить?
Многие пользователи после возникновения сбоя обнаруживают в месте хранения программы системные файлы. Документы носят наименование Debug Dump Files. Можно ли удалить их? Это отладочные файлы, которые создаются после нарушения работы ПО, чтобы помочь определить причину возникновения ошибки. Если вы не пытаетесь устранить проблему, то можете удалить их.