Что мы можем сделать со случайно сбойным приложением без исходного кода? - PullRequest
1 голос
/ 13 января 2009

Я пытаюсь помочь клиенту с проблемой, но у меня заканчиваются идеи. У них есть обычай, написанный в домашнем приложении, который запускается по расписанию, но вылетает. Я не знаю, как давно это происходит, поэтому я не думаю, что смогу отследить сбои до каких-либо конкретных обновлений программного обеспечения. Самое печальное то, что больше нет исходного кода для библиотеки VB6 DLL, которая содержит в себе смысл логики.

Эта библиотека VB6 запускается 2-3 вызовами функций из сценария VB. Очевидно, что я могу изменить скрипт VB для добавления регистрации ошибок, но мне не очень повезло, получая качественную информацию, чтобы точно определить источник сбоя. Я поместил сообщения регистрации по обеим сторонам всех вызовов функций и определил, какой из вызовов вызывает сбой. Однако в объекте err ничего не возвращается, потому что вызов вызывает сбой wscript.exe.

Я не уверен, могу ли я что-нибудь еще сделать. Есть идеи?

Редактировать: Основная причина, по которой меня волнует, хотя у меня нет исходного кода, заключается в том, что может быть какой-то внешний фактор, вызывающий сбой (недостаточные учетные данные, заблокированный файл и т. Д.). Я проверил файл журнала, созданный в файле drwtsn32.log в результате сбоя wscript.exe, и единственной информацией, которую я получаю, является «Нарушение прав доступа».

Сначала я склонен думать, что это как-то связано с разрешениями безопасности, но разве это не может быть нарушением доступа к памяти?

Ответы [ 10 ]

6 голосов
/ 13 января 2009

Вы можете рассмотреть возможность использования одного из инструментов Sysinternals , если действительно считаете, что это проблема среды, такой как права доступа к файлам. Однажды я использовал Filemon, чтобы выяснить все файлы, к которым относилось мое приложение, и обнаружил проблему таким образом.

Вы также можете выполнить быструю проверку работоспособности с помощью Dependency Walker , чтобы убедиться, что вы действительно загружаете DLL-файлы, которые вам нужны. Я видел, что загружалась неправильная версия среды выполнения C, которая вызывала таинственный сбой.

4 голосов
/ 13 января 2009

Вы можете использовать средства отладки для Windows . Что может помочь вам точно определить ошибку, но без источника, который мог бы ее исправить, не принесет вам большой пользы.

Более ленивым способом было бы вызвать dll из кода (не скрипта), чтобы вы могли хотя бы увидеть причину проблемы и проверить объект ошибки. Вы все еще не сможете это исправить, если только проблема не в том, что он вызывается неправильно.

4 голосов
/ 13 января 2009

Всегда можно использовать отладчик - либо непосредственно на ПК, на котором выполняется приложение, вызывающее сбой, либо в дампе памяти, - чтобы определить, что происходит в большей или меньшей степени. В этом случае, когда код VB6, это может быть не очень полезно, потому что вы получите только полезную информацию на уровне Win32.

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

4 голосов
/ 13 января 2009

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

2 голосов
/ 13 января 2009

Есть несколько инструментов, которые могут быть полезны. Во-первых, вы можете использовать средство обхода зависимостей для создания профиля времени выполнения вашего приложения:

http://www.dependencywalker.com/

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

Еще одним полезным инструментом является монитор процесса от Марка Руссиновича:

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

Этот инструмент сообщит обо всех операциях с файлами, реестром и потоками. Это поможет вам определить, сталкивались ли вы с какими-либо проблемами с файлами или реестром.

Process Explorer предоставляет вам много одинаковой информации:

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Это тоже инструмент Руссиновича. Я считаю, что с помощью этого инструмента немного проще взглянуть на некоторые данные.

Наконец, использование средств отладки для Windows или Dev Studio может дать вам некоторое представление о том, где происходят ошибки.

2 голосов
/ 13 января 2009

У парня Coding The Wheel есть довольно интересная серия о создании онлайн покерного бота, который полон серьезной технической информации, многие из которых касаются того, как войти в существующие приложения и связываться с их, что, в некотором роде, то, что вы хотите сделать.

В частности, у него есть статья об использовании WinDbg для получения важной информации , одна о о том, как сгибать вызовы функций к вашему собственному коду и о внедрении DLL в другие процессы . Эти методы могут помочь найти и, возможно, обойти или исправить ошибку, хотя я думаю, что это все еще сложный вызов.

1 голос
/ 14 января 2009

Возможно, вы захотите попробовать Resource Hacker , возможно, вам повезет, декомпилируя внутреннее приложение. он может не дать вам полный исходный код, но, по крайней мере, может дать вам дополнительную информацию о том, что делает приложение, что также может помочь вам определить причину.

1 голос
/ 13 января 2009

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

  1. В самом коде DLL есть ошибка - это может быть что-то вроде ошибки выделения памяти или даже простой ошибки граничного условия цикла.

  2. Есть ошибка, когда DLL пытается соединиться с другой DLL в системе. Обычно это происходит из-за несоответствия версий dll на компьютере.

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

Затем я установил бы систему на чистой машине и попытался воспроизвести ошибку на этом. Запустите монитор и проверьте, какие другие файлы (dll и т. Д.) Открыты при сбое программы. Я видел код, который вылетает на многопоточном Pentium, но не на более раннем, поэтому восстановление старой машины в качестве тестового стенда может быть хорошим вариантом для ее решения. Изменение количества плунжера в машине также имеет смысл.

Надеюсь, эти шаги могут дать вам подсказку. Надеемся, что это будет проблема среды, и поэтому ее можно избежать, используя правильную версию Windows, DLL и т. Д. Однако, если вы все еще застряли с крахом на этом этапе без каких-либо хороших подсказок, то ваши варианты либо переписать, либо попытаться отыщите проблему дальше, отлаживая dll на рычаге ассемблера или разбирая его. Если вы не знакомы с ассемблерным кодом, то оба эти варианта - длинные, и трудно понять, что вы получите, и любой из этих вариантов может привести к значительному сокращению времени. Я сам в прошлом сталкивался с проблемой низкого уровня высокой интенсивности, подобной этой, которая рекламировалась на одном из сайтов «Кодер по найму», и искал кого-то со специальными знаниями. Снова вам понадобится воспроизводимая ошибка, чтобы сделать это.

В долгосрочной перспективе dll без исходного кода придется заменить. Возможно, стоит подумать об оплате специалиста, обладающего навыками сборки, для анализа функций и предоставления вам блок-схем. Хорошей деловой практикой является делать это раньше контролируемым образом, чем позже - например, после того, как компьютер, на котором он работает, вышел из строя и эта версия Windows больше не доступна.

0 голосов
/ 14 января 2009

Обратный инжиниринг - одна из возможностей, хотя и трудная.
Теоретически вы можете декомпилировать и даже отлаживать / отслеживать откомпилированное приложение VB6 - это простая часть, модификация без исходного кода во всех случаях, кроме самых простых, является сложной.

Бесплатные компиляторы / декомпиляторы:

VB декомпиляторы

VB отладчики

Переписывание будет, в большинстве случаев, более успешным и быстрым способом решения проблемы.

0 голосов
/ 13 января 2009

Добавить максимально возможную оперативную память на машину

Этот простой и дешевый хак у меня работал в прошлом. Конечно YMMV.

...