СИСТЕМА И СПОСОБ АВТОМАТИЧЕСКОЙ ОБРАБОТКИ СИСТЕМНЫХ ОШИБОК ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Область техники

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

Уровень техники

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

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

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

Существующие технологии позволяют тестировать программы, в том числе, в эмулируемой среде исполнения. Среди них присутствуют способы симуляции различных состояний системы для выявления возможных ошибок, один из которых описан в патенте US 7203881. Но не все обнаруженные в ходе тестирования ошибки возможно исправить путем коррекции кода приложения. Проблема постобработки ошибок при попытке установки программ и их работе на компьютере приобретает еще большее значение с ростом количества приложений, их обновлений и версий.

Технология, описанная в патенте US 6378128, позволяет корректировать установщик программы для решения возникающих проблем. Применение этого способа неэффективно при установке ПО в корпоративной вычислительной сети (КВС) с большим количеством рабочих станций, для каждой из которых может потребоваться формирование уникального установщика.

Другими вариантами решения проблемы возникновения системных ошибок при установке ПО являются откат состояния системы и использование средств виртуализации для предустановки. В патентных публикациях US 20060168165, US 6691250 описаны примеры подобных систем, но они не позволяют выявить причины возникновения ошибок.

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

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

Сущность изобретения

Настоящее изобретение предназначено для исключения ошибок, возникающих в процессе работы программного обеспечения, в том числе при установке нового или обновлении имеющегося программного обеспечения.

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

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

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

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

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

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

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

В частном варианте реализации эмулятор воспроизводит функции, по меньшей мере, процессора и памяти компьютерной системы.

Один из вариантов реализации содержит эмулятор, который воспроизводит состояние компьютерной системы, изменяя, по меньшей мере, одно возвращаемое значение API-функции операционной системы.

Предложенные варианты реализации обрабатывают ошибки, возникающие в случае вызова исключения, возврата кода ошибки, присвоения значения переменной ошибки, выявления ошибки обработчиком системных событий.

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

Другой вариант сценария обработки ошибки состоит из последовательности команд, позволяющих передать информацию о возникшей ошибке на сервер администрирования.

Краткое описание прилагаемых чертежей

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

Заявленное изобретение поясняется следующими чертежами, на

которых:

Фиг.1 показывает схему исполнения приложения на компьютерном устройстве.

Фиг.2 показывает схему исполнения приложения в эмуляторе.

Фиг.3 показывает структурную схему эмулятора.

Фиг.4 показывает блок схему алгоритма работы эмулятора.

Фиг.5 показывает функциональную схему системы автоматической обработки системных ошибок.

Фиг.6 показывает алгоритм работы системы автоматической обработки системных ошибок.

Фиг.7 показывает пример компьютерной системы общего назначения.

Описание предпочтительных вариантов осуществления

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

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

Рассмотрим пример установщика (инсталлятора) пользовательского приложения. В большинстве случаев программы распространяются в сжатом самораспаковывающемся формате. Процесс установки включает в себя тест системы на соответствие техническим требованиям, распаковку и правильное расположение файлов по директориям на диске, добавление или изменение переменных среды. Для установки некоторых программ и дополнений процесс установки ограничивается копированием файла в соответствующую директорию. Существуют инсталляторы, которые загружают файлы из сети Интернет и изначально не содержат в себе файлов программы. Также применяется модель пакетной установки программ, в которой установщик является частью операционной системы, а ПО распространяется в виде стандартного формата для пакетной обработки.

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

- проверки доступа для записи/чтения необходимого программе файла;

- проверки наличия необходимого свободного места на диске;

- проверки наличия необходимых для функционирования библиотек, интерпретаторов;

- проверки соответствия характеристик процессора, памяти и видеоконтроллера требованиям ПО к вычислительным ресурсам;

- проверки доступности удаленного ресурса по сети передачи данных;

- проверки любого другого параметра системы.

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

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

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

Примеры (кодов ошибок) для Adobe Flash Player:

Для хранения ошибок часто используются глобальные переменные, например в языке Си ошибки хранятся в переменной «errno»:

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

Большинство современных языков программирования, таких как С++, Delphi, Objective-C, Java, Ruby, Python, PHP, все языки платформы .NET и др. имеют встроенную поддержку структурной обработки исключений. В этих языках при возникновении исключения, поддерживаемого языком, происходит раскрытие стека вызовов до первого обработчика исключений подходящего типа и передача управления обработчику.

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

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

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

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

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

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

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

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

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

Некоторые языки программирования позволяют обходиться без предварительной компиляции программы и переводят ее в инструкции машинного кода непосредственно во время исполнения. Этот процесс называется динамической компиляцией и позволяет добиться большей переносимости программ между разными аппаратными и программными платформами. Программы, которые интерпретируются операционной системой или специальными программами-интерпретаторами, называются скриптами или «сценариями». Данные программы также хранятся на диске в виде одиночных файлов или наборов файлов, в которых, содержится исходный код и данные.

В случае, когда программа предварительно откомпилирована и хранится на диске в виде исполняемого файла или набора файлов, процесс загрузки является более быстрым и заключается в переносе образа программы с диска в оперативную память компьютера. Исполняемым файлом (executable file) называется файл, который может быть загружен в память загрузчиком операционной системы и затем исполнен. В операционной системе семейства Windows исполняемые файлы, как правило, имеют расширения ".ехе" и ".dll". Расширение ".ехе" имеют программы, которые могут быть непосредственно запущены пользователем. Расширение ".dll" имеют так называемые динамически связываемые библиотеки (dynamic link libraries). Эти библиотеки экспортируют функции, используемые другими программами. Для того чтобы загрузчик операционной системы мог правильно загрузить исполняемый файл в память, содержимое этого файла должно соответствовать принятому в данной операционной системе формату исполняемых файлов. В современных операционных системах существует множество различных форматов исполняемых файлов. Рассмотрим в качестве примера программу, написанную и скомпилированную для исполнения в операционной системе семейства Windows. Формат Portable Executable (РЕ) - это основной формат для хранения исполняемых файлов и библиотек в операционной системе семейства Windows. Части программ могут компилироваться независимо в отдельные объектные файлы, которые затем объединяются компоновщиком в один исполняемый файл. Исполняемый файл описываемого формата имеет определенную спецификацию. РЕ-файл начинается с заголовков, за которыми располагаются несколько секций. Секция в РЕ-файле представляет либо код, либо некоторые данные и имеет набор атрибутов, задающих ее свойства. Исполняемый файл всегда содержит, по крайней мере, одну секцию, в которую помещен исполняемый код. В общем случае РЕ-файл имеет секции кода (text), данных (data), неинициализированных данных (bss), а также динамически распределяемую область памяти при загрузке - кучу (heap) и стек (stack). Каждая секция имеет собственное предназначение, например сегмент кода содержит непосредственно исполняемые инструкции.

На Фиг.1 показана схема исполнения приложения на компьютерном устройстве, содержащем память и процессор. Приложение, которое может иметь различный функционал, в том числе являться установщиком ПО, представлено на схеме в виде исполняемого файла 100. В других вариантах реализации файл 100 приложения может быть неисполняемым, и для его воспроизведения потребуется дополнительно компилятор или интерпретатор. Исполняемый файл 100 приложения хранится на диске 27 или на другой внешней памяти.

Запуск программ в операционных системах 111 обрабатывает специальный модуль - загрузчик, который создает процесс и потоки, загружает необходимые для начала работы код и данные в память процесса и передает управление приложению. Схема выделения виртуальной памяти 130 описана ниже. Образ РЕ-файла в памяти практически идентичен своему представлению 100 на диске. Данная особенность формата упрощает работу загрузчика, которому достаточно отобразить отдельные части РЕ-файла в адресное пространство процесса, изменить абсолютные адреса в исполняемом коде в соответствии с таблицей релокаций, создать таблицу адресов импорта и затем передать управление на точку входа. В процессе исполнения программы могут потребоваться библиотеки, подгружаемые из каталогов операционной системы или стороннего набора библиотек, ссылки на которые указаны в секции импорта. Таким образом, при запуске программы загрузчик производит следующие действия: считывает заголовки и необходимые секции запускаемого файла 100; загружает в память библиотеки 134, код 132 и данные (ресурсы) 133; выполняет связывание адресов; создает в памяти новый процесс и планирует его к исполнению.

Процессом называется объект операционной системы, содержащий набор ресурсов и данных 133, использующихся при выполнении программы. При этом для каждого процесса создаются потоки, по меньшей мере, один поток на процесс, которые отвечают за исполнение кода 132 процесса и состоят из инструкций. Инструкции или операционный код (опкод) - это операция выполняемая процессором. Современные процессоры обрабатывают инструкции в виде команд языка ассемблера и далее уже конвертируют их во внутреннюю систему команд в виде цифрового кода. Выделение процессорного времени, синхронизация и определение приоритета исполнения кода в операционной системе отводится планировщику. Планирование в ОС семейства Windows осуществляется на уровне потоков, независимо от процессов, которым они принадлежат. После того, как создан процесс и поток, начинается исполнение инструкций потока на процессоре.

По мере исполнения потоков процесса, секции памяти из виртуального адресного пространства 130 загружаются в оперативную память 120. Реальный адрес, по которому размещается секция памяти, скрыт для данного процесса. Неиспользуемые секции переносятся из оперативной памяти 120 на внешнюю память 27 в файл подкачки 140.

Схема исполнения программы в эмуляторе отличается от стандартной схемы и показана на Фиг.2. В представленном варианте реализации компьютерная система дополнена эмулятором 200, который выполнен в виде программы, исполняемой на уровне приложений. В других частных случаях эмулятор может являться частью операционной системы 111 или даже отдельным устройством. Эмулятор 200, загруженный в память 120 компьютерной системы и исполняемый на процессоре 21, осуществляет разбор исполняемого файла 100 и обработку его кода. Характерной особенностью является то, что анализируемое приложение загружается в адресное пространство эмулятора 200. Программная реализация эмулятора позволяет обрабатывать код и ресурсы приложения аналогично процессору 21 и операционной системе 111.

На Фиг.3 показана структурная схема эмулятора 200. Эмулятор 200 компьютерной системы - это средство воспроизведения устройств и программного обеспечения компьютерной системы, взаимодействующее с внешними объектами аналогично компьютерной системе в рамках заданной точности. Предел точности эмулятора - это полное копирование всех программно-аппаратных функций (реализация операционной системы, всех установленных приложений, логики работы всех установленных на компьютере устройств и соединений). В рамках определенного исследования достаточно частичного воспроизведения функционала и состояния компьютерной системы. Для упрощения эмуляции компьютерной системы используют методы для перехвата запросов к объектам компьютерной системы, которые не были эмулированы, для перенаправления запросов реальным объектам компьютерной системы. В одном из вариантов реализации для построения эмулятора, способного исполнить код программы требуется воссоздание процессора 300 и памяти 310. Дополнительно в эмулятор включают файловую систему 320, устройства ввода/вывода 330 и сеть передачи данных 340. В некоторых примерах реализации возможно воспроизведение функций операционной системы и внешних сервисов. Как описывалось ранее, процесс исполняемого файла 311 воспроизводится в адресном пространстве эмулятора, в котором происходит его размещение в воссозданной памяти 310. Для контроля программных инструкций, которые обрабатываются в эмуляторе 200 и при необходимости должны быть переданы на исполнение в реальную среду, выделяется отдельный функциональный блок - обработчик запросов 350. Ход исполнения программы в эмуляторе в виде последовательности выполняемых команд ведется модулем журналирования 360.

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

Фиг.4 отображает блок-схему алгоритма работы эмулятора 200 для определения полного перечня системных ошибок, которые могут возникнуть в ходе исполнения кода приложения при различных состояниях и конфигурациях компьютерной системы. Начало эмуляции работы программы 400 может быть инициировано рядом событий (в зависимости от интерпретации), среди которых запуск приложения на исполнение; передача приложения (файлов или процесса приложения) на анализ в эмулятор; сохранение в памяти компьютера приложения, которое ранее не анализировалось и другие системные события. Перехват событий, служащих началом эмуляции приложения, может быть реализован, например, внедрением специального драйвера, обрабатывающего вызовы к операционной системе. После того, как код, ресурсы приложения и необходимые библиотеки загружены в эмулятор, приложение начинает выполняться в эмулируемой среде, где каждая инструкция обрабатывается 405 в эмуляторе обработчиком запросов 350 и сохраняется 420 в модуле журналирования 360.

Рассмотрим вариант реализации системы, в котором в качестве условного ветвления выступает вызов API-функции. При перехвате следующей в хронологическом порядке API-функции эмулятор возвращает приложению заведомо ложное значение 410, после чего программа продолжает исполняться до возникновения ошибки (возврата кода определенной ошибки 415). Эмулятор в каждом цикле последовательно возвращает различные коды ошибок в зависимости от спецификации вызываемой функции. Код ошибки и журнал исполнения программы сохраняются 420, а эмуляция переходит к следующему циклу, в котором весь процесс повторяется, но ложное значение возвращается только от следующей API-функции 430. Количество циклов соответствует количеству вызываемых функций с учетом того, что каждая функция может вернуть несколько, различных кодов ошибок. Выход из цикла происходит, когда обработаны все вызовы функций 425. В результате данных манипуляций в журнале создаются записи о кодах ошибок и вызовах функций, значения которых были подменены. Возврат ложного результата функции означает невыполнение одной из команд программы, что приводит к ошибке в работе программы, которую определяет значение кода ошибки. Функция, вызов которой привел к формированию ошибки, трактуется в качестве причины ее возникновения. Полученные результаты составляют экспертные данные, дающие представление об ошибках и вызвавших указанные ошибки причинах 435. Далее определяются инструкции 440 - действия, направленные на обработку ошибки. Например, если причиной возникновения сбоя послужила попытка чтения файла, необходимо проверить его наличие и настроить разграничение прав доступа.

Существует набор функций, перебор и анализ которых не даст результата. Для ускорения исследования программы данные функции пропускаются, тем самым уменьшается количество циклов эмуляции. Перечень функций, которые не несут смысловой нагрузки для выявления причин ошибок, заносятся в специальный список, который может быть в дальнейшем дополнен и модифицирован. Рассмотрим пример трассировки приложения, в котором многие функции не будут влиять на код возвращаемой ошибки. Функция CreateFileW не получила доступ к файлу ebO.tmp, например, потому, что файл используется. После этого выполнилось несколько вызовов функций и финальный вызов ExitProcess с кодом возврата 0×401. Журнал вызовов содержит последовательность вызываемых функций и их результатов, следующих за функциями, возвращаемые значения которых были изменены, и показан ниже:

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

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

Далее более детально описано устройство основных узлов компьютерной системы, которые участвуют в исполнении кода программы и входят в состав эмулятора 200.

Рассмотрим устройство процессора 300 на примере архитектуры ×86. Каждая архитектура характеризуется набором команд процессора, схемой работы с памятью, таблицей декодирования команд и т.д. Помимо основного набора команд, то есть команд, с помощью которых можно выполнить любую программу, процессоры семейства ×86 имеют расширения в виде специальных возможностей, реализуемых компанией-производителем. К подобным расширениям, как правило, относятся команды оптимизации исполнения инструкций, использование специальных режимов исполнения инструкций и другие.

Основными элементами процессора являются исполняющие устройства 302, которые непосредственно выполняют все инструкции. Среди них можно выделить две основные группы: арифметико-логические устройства (ALU) и блок вычислений с плавающей точкой (FPU).

В современных процессорах команды потоков отличаются от операций, которые реализуют исполняющие устройства. Это сделано для упрощения работы исполняющих устройств и увеличения скорости работы процессора. Для преобразования ×86 совместимого кода во внутреннюю систему команд исполняющих устройств используется декодер 301.

Развитие процессорной техники привело к появлению кэша, ускоряющего исполнение программ. Кэш представляет собой временную память, доступ к которой на порядок быстрее, чем чтение данных из ОЗУ (оперативно запоминающее устройство). Когда поток начинает выполняться, загружаемые из процесса ресурсы сохраняются в кэше, перезаписывая в нем устаревшие данные. Далее, перед тем как загрузить данные из ОЗУ, процессор проверяет их наличие в кэше, тем самым экономит время на выполнение программы. В современных процессорах поддерживается многоуровневое кэширование, разделяющее кэш данных, кэш инструкции, смешанный кэш и т.д.

Самой быстрой памятью являются регистры 303, которые располагаются непосредственно в ядре процессора. Пример 32-разрадного процессора содержит восемь регистров общего назначения, которые могут использоваться для хранения данных и адресов, шесть регистров сегментов, регистры состояния и управления и специальные регистры.

Процессор может работать в нескольких режимах. Основными из них являются реальный и защищенный режимы. Переключения между режимами происходят программно. Работа процессора в реальном режиме характеризуется выполнением 16-разрядных команд, 20-разрядной адресацией и незащищенностью адресного пространства одной программы от другой. Современные операционные системы, поддерживающие многозадачность, используют защищенный режим. Новый метод адресации памяти позволяет изолировать адресные пространства отдельных задач друг от друга. При этом прикладная программа, работающая в среде операционной системы, использующей защищенный режим, не может случайно или намеренно разрушить целостность самой операционной системы. В защищенном режиме программа может записывать данные только в те области памяти, которые выделены ей операционной системой. Это повышает надежность работы многозадачных и, в частности, многопользовательских операционных систем. Именно в защищенном режиме возможно страничное управление памятью, которое позволяет поместить часть оперативной памяти на диске. Страничная организация памяти - простая схема повышения эффективности, в соответствии с которой память разбивается на страницы от 512 байт до нескольких килобайт. Соответствующая схема обращения позволяет в пределах страницы уменьшить количество состояний ожидания.

Все потоки процесса выполняются в едином адресном пространстве, выделяемом при создании процесса. В 32 разрядных системах объем памяти, доступной каждому процессу, составляет 4 Гбайт. Верхняя половина этого пространства резервируется за операционной системой, а вторая половина доступна пользовательским приложениям.

Механизм виртуальной памяти позволяет изолировать процессы друг от друга. Потоки одного процесса не могут ссылаться на адресное пространство другого процесса. Виртуальная память 130 может вовсе не соответствовать структуре физической памяти 120. Диспетчер памяти транслирует виртуальные адреса на физические, по которым реально хранятся данные. Поскольку далеко не всякий компьютер в состоянии выделить по 4 Гбайт физической памяти на каждый процесс, используется механизм подкачки (swapping). Когда оперативной памяти не хватает,

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

Для эмуляции процессов часто необходимо эмулировать файловую систему, особенно в тех случаях, когда необходимо обезопасить данные на диске или когда доступ к файлам ограничен. Файловой системой называется способ организации, хранения и именования данных на носителях информации. Оперируя объектами данных в виде файлов, операционная система использует файловую систему для размещения файлов на диске и обращения к ним, а также для определения атрибутов файла, разграничения доступа и т.д. С точки зрения ОС весь диск представляет собой набор кластеров. Драйверы файловой системы организуют кластеры в файлы и каталоги. Когда приложение обращается к файлу, файловая система определяет кластеры, в которых хранится файл и передает запрос на чтение данных секторов драйверу диска.

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

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

Например, команда копирования MOV, имеющая два параметра Dest (адрес назначения) и Source (источник копирования) реализуется одной внутренней операцией Dest:=Source (для семейства процессоров ×86). Существуют команды, которые выполняются в несколько операций. Например, команда обмена Exchange, которая меняет значения, хранящиеся по двум адресам, реализуется двумя операциями Op1:=Op2, Ор2:=Ор1.

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

В современных операционных системах практически все взаимодействие приложения с устройствами и сервисами компьютерной системы, например, открытие файла или загрузка веб-страницы, осуществляется через API-функции (Application Programming Interface). Последовательность вызываемых функций составляет шаблон поведения приложения, позволяет определить характер приложения и в некоторых случаях идентифицировать код.

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

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

Рассмотрим пример трассировки программы, в котором журнал эмуляции представляет собой следующий список:

Список содержит вызовы функций с определенными параметрами. Основной задачей является определение поведения приложения, если вызов функции приведет к ошибке. Для этого для каждой API-функции приложению возвращается код ошибки вместо ожидаемого значения. В одном из вариантов реализации возврат ошибок производится последовательно и поочередно для каждой функции. Например, на первом запуске приложение будет обмануто и вызов функции GetProcAddress вернет 0 даже в том случае, если в реальной системе вызов функции вернул бы другое значение (0x1a494bbe), соответствующее успешному выполнению. На втором запуске вызов функции URLDownloadToFileA вернет не 0 (0xFFFFFFFF), на третьем запуске Sleep вернет не 0, на четвертом запуске DeleteFileA вернет false и так далее.

При каждом запуске приложение продолжит эмулироваться до конца с учетом того, что вызов функции возвращает намеренно измененное значение, и продолжает вести журнал эмуляции. Код возврата отличный от нуля будет означать появление определенных условий, которые следует учитывать при запуске и установке приложения. Например, отсутствие функции URLDownloadToFileA в библиотеке приводит к коду ошибки 3333; невозможность соединения по ссылке URL в сети Интернет приводит к коду ошибки 3334; невозможность системы перейти в режим Sleep приводит к завершению работы приложения; невозможность удаления файла приводит к коду ошибки 7777 и т.д.

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

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

На Фиг.5 показана функциональная схема варианта осуществления системы автоматической обработки системных ошибок. Система состоит из сервера администрирования 500 и агентов администрирования 530, распределенных по КВС. Агенты администрирования 530, установленные на персональных компьютерах 510, мобильных устройствах и других элементах КВС, подключенных к серверу администрирования 500, предназначены для сбора информации о ходе исполнения программных инструкций, настройке системы и обработке системных событий, в том числе ошибок. Работу агентов контролирует установленный на сервере администрирования 500 модуль управления установкой 520, который формирует задания на установку 523 нового ПО, анализирует ошибки, которые могут возникнуть в ходе установки, и хранит экспертные данные, необходимые для принятия решений в ходе обработки ошибок и настройки компьютерных систем.

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

Обновление существующих приложений и установка нового программного обеспечения являются одними из ключевых задач администратора сети, который формирует список заданий на установку 523. Список установки новых программных компонент может формироваться как вручную, так и автоматически, например, добавляя новые задания при получении информации о выходе обновлений и новых версий ПО.

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

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

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

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

Получив задание на установку ПО, агент администрирования 530 загружает установщик ПО 531 (инсталлятор) и связанные с ним экспертные данные, в которых могут быть рекомендации по изменению конфигурации системы и дополнительные пакеты программ, без которых задание на установку будет выполнено с ошибками или некорректно. Настройку компьютерной системы и всех ее компонент производит конфигуратор 533. В некоторых вариантах реализации конфигуратор и установщик ПО 531 являются встроенными сервисами операционной системы.

Пользователь может производить установку самостоятельно, загрузив инсталлятор и отправив его на исполнение. В этом случае, а также в случае, если рекомендации по изменению конфигурации системы не были приняты, в ходе установки программы и в процессе ее работы могут возникнуть ошибки, обработать которые без обращения к службе поддержки затруднительно. Решение данной проблемы без применения описываемой технологии полностью зависит от внешних факторов. Чтобы исправить данную ситуацию, в системе автоматической обработки системных ошибок предусмотрен обработчик ошибок 532 на стороне персонального устройства 510, который перехватывает код ошибки, обращается в экспертную базу данных 521 за справкой и производит определенные в ней действия для исключения повтора ошибки.

Экспертная база данных 521 пополняется по результатам анализа программ. При этом база данных 521 может храниться на сервере 500 в локальной сети, на персональном устройстве 510 или на удаленном сервере 540, доступ к которому осуществляется через глобальную сеть Интернет. Данная схема разделения баз данных наиболее оптимальна в случае, когда анализ программного обеспечения производится распределенно. В том случае, если решение для возникшей ошибки отсутствует в локальной базе данных, запрос отправляется в вышестоящий сервер администрирования. Центральным сервисом для пополнения и хранения, а также синхронизации экспертных данных является лаборатория исследования программ. В другом примере реализации, обновление и синхронизация данных могут быть децентрализованными, например, с применением Р2Р-сетей.

На Фиг.6 изображен алгоритм работы системы автоматической обработки системных ошибок с указанием этапов, каждый из которых может выполняться на сервере администрирования 500 и на персональном устройстве КВС 510. Процесс автоматической установки нового или обновления существующего ПО начинается загрузкой нового ПО 600 (инсталляторов, упакованных файлов, исходных файлов). Данное ПО должно быть протестировано на совместимость со средой исполнения, в которую планируется установка ПО. Для этого на этапе 605 производится эмуляция процесса установки. Средствами эмулятора воспроизводится соответствующее окружение: процессор, память, ОС, файловая система и другое. Недостаток детализации эмулятора может быть скомпенсирован перенаправлением запросов реальным объектам системы. Например, часть инструкций программы может быть исполнена на реальном процессоре, вызов API-функций может быть адресован в реальную ОС, а запрос веб-серверу может быть отправлен через подключенную сеть передачи данных. Следующим этапом является построение дерева ошибок 610, которое отражает причинно-следственную связь возвращаемого значения ошибки и условий ее возникновения, фиксируемых эмулятором в модуле журналирования. Для каждой ошибки создается набор инструкций (сценарий) для исправления данной ошибки.

Запись полученных результатов в упорядоченном виде в экспертную базу данных осуществляется на этапе 615. Впоследствии данная база может содержать также информацию об эффективности примененных правил и точности описания ошибок. Далее формируется задание на установку нового ПО 620, после чего действие переходит на персональное устройство. Задание на установку нового ПО 625 содержит инсталлятор и/или ссылку на него и инструкции для приведения конфигурации системы к требуемому состоянию, которые добавляются в задание из экспертной базы данных. Получив новое задание 625, агент администрирования 530 производит установку дополнительных программных модулей, настройку программ и устройств в соответствии с рекомендациями, содержащимися в задании. Конфигурация компьютера пользователя для предотвращения появления системных ошибок производится на этапе 630. Данному этапу может предшествовать дополнительный шаг тестирования компьютерной системы для определения пунктов расхождения текущей конфигурации персонального устройства и технических требований для корректной установки и работы ПО.

Следующий этап выполнения установки нового ПО - это этап 635, на котором выполняются операции установщика: распаковка, копирование и создание файлов, редактирование системного реестра, регистрация на удаленном сервере и другие. В ходе исполнения данного процесса могут возникнуть ошибки или исключения, которые необходимо обработать 645 в автоматическом режиме. Отслеживание ошибок производится на этапе 640. Системное событие, характеризующее ошибку, перехватывается и анализируется, определяется код ошибки и условия, при которых она возникла. По этим данным осуществляется поиск связанной информации в экспертной базе данных. Обработка 645 ошибки предполагает выполнение сценария обработки для ее исправления, оповещение пользователя и/или администратора об ошибке с полным описанием причин возникновения и способов исправления ошибки. Опционально обработка ошибок позволяет уточнять экспертные данные, дополняя перечень состояний системы, приводящих к данным ошибкам, и корректировать инструкции по их исправлению. Процесс установки завершается 650, когда все возникшие ошибки обработаны, и программное обеспечение корректно установлено на персональном устройстве.

Далее описан пример компьютерной системы, архитектура которой лежит в основе сервера администрирования, персонального устройства и компьютерной системы, элементы которой воспроизводит эмулятор.

Фиг.7 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер 20, содержащий центральный процессор 21, системную память 22 и системную шину 23, которая содержит разные системные компоненты, в том числе память, связанную с центральным процессором 21. Системная шина 23 реализована, как любая известная из уровня техники шинная структура, содержащая в свою очередь память шины или контроллер памяти шины, периферийную шину и локальную шину, которая способна взаимодействовать с любой другой шинной архитектурой. Системная память содержит постоянное запоминающее устройство (ПЗУ) 24, память с произвольным доступом (ОЗУ) 25. Основная система ввода/вывода (BIOS) 26, содержит основные процедуры, которые обеспечивают передачу информации между элементами персонального компьютера 20, например, в момент загрузки операционной системы с использованием ПЗУ 24.

Персональный компьютер 20 в свою очередь содержит жесткий диск 27 для чтения и записи данных, привод магнитных дисков 28 для чтения и записи на сменные магнитные диски 29 и оптический привод 30 для чтения и записи на сменные оптические диски 31, такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск 27, привод магнитных дисков 28, оптический привод 30 соединены с системной шиной 23 через интерфейс жесткого диска 32, интерфейс магнитных дисков 33 и интерфейс оптического привода 34 соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера 20.

Настоящее описание раскрывает реализацию системы, которая использует жесткий диск 27, сменный магнитный диск 29 и сменный оптический диск 31, но следует понимать, что возможно применение иных типов компьютерных носителей информации 56, которые способны хранить данные в доступной для чтения компьютером форме (твердотельные накопители, флеш карты памяти, цифровые диски, память с произвольным доступом (ОЗУ) и т.п.), которые подключены к системной шине 23 через контроллер 55.

Компьютер 20 имеет файловую систему 36, где хранится записанная операционная система 35, а также дополнительные программные приложения 37, другие программные модули 38 и данные программ 39. Пользователь имеет возможность вводить команды и информацию в персональный компьютер 20 посредством устройств ввода (клавиатуры 40, манипулятора «мышь» 42). Могут использоваться другие устройства ввода (не отображены): микрофон, джойстик, игровая консоль, сканнер и т.п. Подобные устройства ввода по своему обычаю подключают к компьютерной системе 20 через последовательный порт 46, который в свою очередь подсоединен к системной шине, но могут быть подключены иным способом, например, при помощи параллельного порта, игрового порта или универсальной последовательной шины (USB). Монитор 47 или иной тип устройства отображения также подсоединен к системной шине 23 через интерфейс, такой как видеоадаптер 48. В дополнение к монитору 47, персональный компьютер может быть оснащен другими периферийными устройствами вывода (не отображены), например колонками, принтером и т.п.

Персональный компьютер 20 способен работать в сетевом окружении, при этом используется сетевое соединение с другим одним или несколькими удаленными компьютерами 49. Удаленный компьютер (или компьютеры) 49 являются такими же персональными компьютерами или серверами, которые имеют большинство или все упомянутые элементы, отмеченные ранее при описании существа персонального компьютера 20, представленного на Фиг.7. В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.

Сетевые соединения могут образовывать локальную вычислительную сеть (LAN) 50 и глобальную вычислительную сеть (WAN). Такие сети применяются в КВС, внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер 20 подключен к локальной сети 50 через сетевой адаптер или сетевой интерфейс 51. При использовании сетей персональный компьютер 20 может использовать модем 54 или иные средства обеспечения связи с глобальной вычислительной сетью, такой как Интернет. Модем 54, который является внутренним или внешним устройством, подключен к системной шине 23 посредством последовательного порта 46. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.

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

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