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

Изобретение относится к области вычислительной техники. Техническим результатом является обеспечение определения модуля приложения, связанного с причиной неполадки, возникшей при работе приложения. Раскрыт способ определения модуля приложения, связанного с причиной неполадки, возникшей при работе приложения, реализуемый компьютером, в котором: а) отключают по меньшей мере один модуль приложения в соответствии с правилом диагностики для упомянутой неполадки; б) проверяют устранение неполадки вследствие отключения по меньшей мере одного модуля приложения; и в) в случае устранения неполадки определяют по меньшей мере один упомянутый модуль приложения как связанный с причиной неполадки. 15 з.п. ф-лы, 5 ил., 1 табл.

 

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

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

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

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

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

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

Раскрытие сущности изобретения

Технический результат заключается в реализации назначения.

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

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

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

Согласно еще одному варианту реализации порядок отключения модулей приложения зависит от частоты возникновения неполадки из-за соответствующего модуля приложения.

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

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

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

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

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

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

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

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

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

Согласно одному из вариантов реализации обновляют правила диагностики с использованием удаленного сервера.

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

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

Краткое описание чертежей

Дополнительные цели, признаки и преимущества настоящего изобретения будут очевидными из прочтения последующего описания осуществления изобретения со ссылкой на прилагаемые чертежи, на которых: На Фиг. 1 представлен пример архитектуры операционной системы (ОС).

На Фиг. 2 приведен возможный набор модулей приложения на примере антивирусного приложения.

На Фиг. 3 представлен способ определения модуля приложения, связанного с причиной неполадки, возникшей при работе приложения.

На Фиг. 4 представлен пример реализации способа устранения неполадки, возникшей при работе приложения.

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

Осуществление изобретения

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

На Фиг. 1 представлен пример архитектуры операционной системы (ОС). После загрузки операционной системы, установленной на компьютере пользователя 100, процессор компьютера может работать в пользовательском режиме (англ. user mode) или в режиме ядра (англ. kernel mode). В пользовательском режиме приложения имеют доступ только к своему виртуальному адресному пространству и не имеют доступ к адресному пространству других приложений или адресному пространству, зарезервированному ОС. В этом режиме работают приложения 110 и драйверы пользовательского режима 130. Приложения, выполняющиеся в режиме ядра имеют общее адресное пространство. В режиме ядра работают драйверы режима ядра 140, ядро операционной системы 160 и соответственно подпрограммы поддержки драйверов 150.

Приложения 110, а также драйверы пользовательского режима 130 взаимодействуют с ядром операционной системы 160 посредством интерфейса прикладных программ 120 (англ. application program interface - API). Драйверы режима ядра 140 используются для взаимодействия ядра ОС 160 и драйверов пользовательского режима 130 с аппаратным обеспечением 180 через слой аппаратных абстракций 170 (англ. Hardware Abstraction Layer - HAL). Кроме того, драйверы режима ядра 140 могут включать фильтр-драйверы, которые расширяют или изменяют поведения устройств. Изобретение, раскрываемое в настоящей заявке, служит для определения модуля приложения 111, связанного с причиной неполадки, возникшей при работе приложения 111. Для определенности, приложения 112-113 будут называться сторонними приложениями 112-113 по отношению к приложению 111. Приложение 111 может быть любым программный обеспечением, установленным на компьютере пользователя 100, в частности, антивирусным приложением. Далее, для определенности, приложение 111 будет рассматриваться на примере антивирусного приложения.

Приложение 111 содержит модули определенного функционала. К числу таких модулей могут относиться некоторые драйверы пользовательского режима 130 и драйверы режима ядра 140, необходимые для выполнения функционала приложения. Особенностью большинства современных приложений, в частности, антивирусных приложений является наличие большого количества модулей, таких как файловый сканер, эмулятор, сетевой экран, различные драйверы, например, фильтр-драйверы и другие модули (более подробно модули приложения описаны на Фиг. 2). Таким образом, в процессе работы приложения 111 могут возникать различные неполадки (повышенная нагрузка на процессор по сравнению с обычной нагрузкой на процессор при работе упомянутого модуля, снижение производительности, зависание ОС и др.). Такие неполадки могут быть вызваны программными ошибками в одном из модулей приложения 111. Также неполадки могут быть вызваны несовместимостью одного из модулей приложения 111 со сторонними приложениями 112-113 из-за программных ошибок в сторонних приложениях 112-113. В еще одном примере, неполадки могут быть вызваны несовместимостью одного из модулей приложения с ОС 160 или драйверами пользовательского режима 130 или драйверами режима ядра 140. Например, если модуль приложения 111 обращается к функции драйвера режима ядра 140, при этом в упомянутом драйвере присутствует ошибка, то может возникнуть неполадка, такая как перезагрузка компьютера. Для решения заявленной технической проблемы и достижения технического результата используется способ определения модуля приложения, связанного с причиной неполадки, возникшей при работе приложения, реализуемый компьютером, а именно средством диагностики 115. Средство диагностики 115 является одним из приложений 110. В частном примере реализации средство диагностики 115 является модулем приложения 111. В другом частном примере реализации, средство диагностики 115 является отдельным приложением.

На Фиг. 2 приведен возможный набор модулей приложения 111 на примере антивирусного приложения. Антивирусное приложение может содержать модули, предназначенные для обеспечения безопасности компьютера: файловый сканер, почтовый антивирус, веб-антивирус, модуль проактивной защиты, модуль HIPS (англ. Host Intrusion Prevention System - система предотвращения вторжений), DLP-модуль (англ. data loss prevention - предотвращение утечки данных), сканер уязвимостей, эмулятор, сетевой экран и др. В частном примере реализации указанные модули могут быть составной частью антивирусного приложения. В еще в одном примере реализации данные модули могут быть реализованы в виде отдельных программных компонентов.

Файловый сканер содержит функционал обнаружения вредоносной активности файлов на компьютерной системе пользователя. Файловый сканер может работать в различных режимах, например, в режиме сканирования файлов по доступу (англ. on-access scanner) или по требованию (англ. on-demand scanner). В режиме сканирования файлов по доступу, сканируют открываемые, запускаемые и сохраняемые файлы. В режиме сканирования файлов по требованию сканируют заданные пользователем файлы и директории по требованию пользователя.

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

На Фиг. 3 представлен способ определения модуля приложения, связанного с причиной неполадки, возникшей при работе приложения, реализуемый компьютером, а именно средством диагностики 115. На шаге 301 средство диагностики 115 получает информацию о неполадке, возникшей при работе приложения. Такая информация о неполадке может включать, в частности, факт наличия неполадки, тип неполадки. Информация о неполадке может быть получена, например, от пользователя компьютера или от одного из модулей приложения 111, который зафиксировал неполадку, а также от ОС (например, из дампов памяти или при критической ошибке ядра ОС). Модуль приложения 111 может определить наличие неполадки и соответствующий тип неполадки, например, если произошло нештатное завершение работы указанного модуля или если ресурсы приложения 111 или ОС стали недоступны.

Затем, на шаге 302 отключают по меньшей мере один модуль приложения в соответствии с правилом диагностики для данного типа неполадки. Далее, на шаге 303 проверяют устранение неполадки вследствие отключения по меньшей мере одного модуля приложения. И, в случае устранения неполадки (шаг 304), на шаге 305 определяют по меньшей мере один модуль приложения, как связанный с причиной неполадки. При этом, в одном примере реализации в случае сохранения неполадки (шаг 306) повторяют шаги 302-304 с учетом правила диагностики и результатов выполнения проверки на шаге 303, до наступления одного из условий: устранения неполадки либо невозможности устранения неполадки после отключения модулей приложения в соответствии с правилом диагностики, при этом определяют отсутствие модулей приложения, связанных с причиной неполадки (шаг 307). В еще одном частном примере реализации, перед повторением шагов 302-304, включают по меньшей мере один ранее отключенный модуль. При этом, в случае отсутствия модулей приложения, связанных с причиной неполадки, отключенные ранее модули приложения 111 будут вновь включены для корректной работы приложения 111.

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

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

В частном примере реализации правило диагностики определяет порядок отключения (или включения) модулей приложения 111 для проверки устранения неполадки. В еще одном частном примере реализации порядок отключения модулей приложения зависит от частоты возникновения неполадки из-за соответствующего модуля приложения.

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

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

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

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

Возможные правила диагностики для приложения 111 на примере антивирусного приложения (см. Фиг. 2) представлены в таблице 1. Так, при снижении сетевого трафика, согласно правилу 1 из таблицы 1, на шаге 302 первым отключают модуль самозащиты. Затем, после выполнения шага 303 на шаге 304 проверяют устранение неполадки. И, если неполадка не будет устранена, шаги 302-303 повторяют для сетевого экрана. Аналогично, если неполадка не будет устранена, шаги 302-303 повторяют для сканера уязвимости. Т.к. сканер уязвимости - последний модуль в правиле 1, то в случае сохранения неполадки после отключения сканера уязвимости, на шаге 307 определяют отсутствие модулей приложения, связанных с причиной неполадки. То есть причина неполадки не в приложении 111 и не в модулях приложения 111.

Правило 2 также служит для определения неполадки типа «снижение сетевого трафика». Правило 2 соответствует шагу 304а. Согласно правилу 2 вначале отключают приложение 111 целиком (то есть все модули приложения), чтобы определить, связана ли неполадка с приложением 111. Затем локализуют модуль или несколько модулей, связанных с неполадкой. Таким образом, далее возобновляют работу приложения 111, после чего отключают сетевой экран и, если это не устранит неполадку, отключают веб-антивирус.

При этом, если и отключение веб-антивируса не привело к устранению неполадки, определяют целиком приложение 111 как связанное с неполадкой. Правило 3 в таблице 1 может применяться, когда тип неполадки заключается в недоступности ресурсов стороннего приложения, например, если почтовый клиент не отправляет и не принимает почту. В этом случае будет отключен почтовый антивирус.

В частном примере реализации правила диагностики дополнительно зависят, в частности, от одного из:

а) версии приложения;

б) версий модулей упомянутого приложения;

в) версии ОС;

г) установленных сторонних приложений;

д) установленного оборудования компьютера;

е) установленных драйверов.

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

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

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

При этом, тип неполадки является, в частности, одним из:

а) аварийным завершением работы операционной системы;

б) выгрузкой процесса приложения из памяти;

в) зависанием приложения;

г) зависанием операционной системы;

д) повышенной нагрузкой на процессор по сравнению с типичной нагрузкой на процессор при работе упомянутого модуля;

е) снижением производительности по сравнению с типичным значением производительности при работе упомянутого модуля;

ж) избыточным использованием ресурсов;

з) снижением скорости сетевого трафика;

и) недоступностью сети;

к) наличием программной ошибки в коде модуля упомянутого приложения;

л) наличием программной ошибки в коде по меньшей мере одного стороннего приложения, установленного на компьютере;

м) наличием программной ошибки в операционной системе;

н) предоставлением несанкционированного доступа; о) наличием известной уязвимости.

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

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

В одном из частных примеров реализации при отключении определенных модулей запрашивают подтверждения отключения упомянутых модулей у пользователя. Запрос подтверждения может заключаться в необходимости ввести пароль, ввести капчу (англ. от САРТСНА - англ. Completely Automated Public Turing test to tell Computers and Humans Apart - полностью автоматизированный публичный тест Тьюринга для различения компьютеров и людей), нажать подтверждающую кнопку, отправить подтверждающую команду и пр.

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

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

На Фиг. 4 представлен пример реализации способа устранения неполадки, возникшей при работе приложения. После устранения неполадки (шаг 304) проверяют, возможно ли отключить меньшее количество модулей приложения (шаг 304а). Это необходимо, чтобы более точно определить, какой именно модуль приложения связан с причиной неполадки в том случае, если на шаге 302 было отключено два или более модулей приложения. В случае положительного ответа, на шаге 401 включают по меньшей мере один модуль приложения из числа отключенных модулей приложения в соответствии с правилом диагностики для упомянутой неполадки. Затем, на шаге 402 проверяют сохранение неполадки вследствие включения по меньшей мере одного модуля приложения.

В случае сохранения неполадки, определяют по меньшей мере один упомянутый модуль приложения, как связанный с причиной неполадки (шаг 305). А в случае устранения неполадки, повторяют шаги 401-402 для по меньшей мере одного другого модуля приложения из числа отключенных модулей приложения.

В частном примере реализации, если после отключения по меньшей мере двух модулей приложения, неполадка устранена (шаг 403), то включают по меньшей мере один модуль приложения из числа отключенных в соответствии с правилом диагностики для упомянутой неполадки и проверяют сохранение неполадки. При этом, если после включения по меньшей мере двух модулей приложения, ранее устраненная неполадка воспроизводится (шаг 402), то отключают по меньшей мере один модуль приложения из числа включенных в соответствии с правилом диагностики для упомянутой неполадки и проверяют устранение неполадки (шаги 403, 302, 303). Это необходимо, чтобы более точно определить, какой именно модуль приложения связан с причиной неполадки в том случае, если на шаге 401 было включено два или более модулей приложения.

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

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

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

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

Стоит отметить, что частные варианты реализации, описанные к способу по Фиг. 3, также применимы и к способу по Фиг. 4.

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

Фиг. 5 представляет пример компьютерной системы общего назначения, с помощью которой может быть реализовано настоящее изобретение. Персональный компьютер или сервер 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, представленного на Фиг. 5. В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.

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

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

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

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

а) отключают по меньшей мере один модуль приложения в соответствии с правилом диагностики для упомянутой неполадки;

б) проверяют устранение неполадки вследствие отключения по меньшей мере одного модуля приложения; и

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

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

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

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

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

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

а) устранения неполадки;

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

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

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

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

10. Способ по п. 1, в котором тип неполадки является, в частности, одним из:

а) аварийным завершением работы операционной системы;

б) выгрузкой процесса приложения из памяти;

в) зависанием приложения;

г) зависанием операционной системы;

д) повышенной нагрузкой на процессор по сравнению с типичной нагрузкой на процессор при работе упомянутого модуля;

е) снижением производительности по сравнению с типичным значением производительности при работе упомянутого модуля;

ж) избыточным использованием ресурсов;

з) снижением скорости сетевого трафика;

и) недоступностью сети;

к) наличием программной ошибки в коде модуля упомянутого приложения;

л) наличием программной ошибки в коде по меньшей мере одного стороннего приложения, установленного на компьютере;

м) наличием программной ошибки в операционной системе;

н) предоставлением несанкционированного доступа;

о) наличием известной уязвимости.

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

12. Способ по п. 1, в котором модуль приложения является, в частности, одним из: компонентом приложения, драйвером, библиотекой.

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

14. Способ по п. 1, в котором обновляют правила диагностики с использованием удаленного сервера.

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

16. Способ по п. 1, в котором правило диагностики зависит, в частности, от одного из:

а) версии приложения;

б) версий модулей упомянутого приложения;

в) версии ОС;

г) установленных сторонних приложений;

д) установленного оборудования компьютера;

е) установленных драйверов.