Ошибка bcd1695 при обработке вашей транзакции

Result Code Description Как решить проблему Куда обратиться

76

51

076

9859

116

603

Insufficient funds

Not sufficient funds

Decline, not sufficient funds

Decline, not sufficient funds На балансе карты недостаточно средств Если на карте баланс больше или равен сумме транзакции, а отказ все равно происходит по причине недостатка средств, тогда возможны такие причины:
— банк-эмитент удерживает дополнительные комиссии с держателя карты. Это может возникать в случаях погашение кредита посредством интернет-платежа, либо если договор на обслуживание банковской карты предусматривает дополнительные комиссии;
— происходит конвертация из валюты покупки в валюту карты. Убедитесь, что средств на карте достаточно для покрытия комиссии за конвертацию валют. Некоторые банки-эмитенты устанавливают комиссии на конвертацию валют как-правило в пределах 1% Банк-эмитент (банк, выпустивший карту)

50

5

9905

180

Transaction declined

Do not honor

Do not Honour

Transaction declined

Do not honor Не обслуживать Пожалуй, самый общий и не определенный код отказа. Он может указывать на любые ограничения, наложенные банком-эмитентом, которые банк пожелал оставить не уточненными.
Возможные причины:
— карта заблокирована или на ней установлен статус
— на карте не установлен лимит на оплату в интернет, либо этот лимит недостаточный
— сработали настройки системы безопасности банка-эмитента
— сработали ограничения по сумме или количеству операций по карте у банка-эмитента
— банк-эмитент установил ограничения на проведение данного типа транзакций
— по карте не разрешены международные платежи (доместиковая карта)
— банк-эмитент установил ограничение на транзакции с двойной конвертацией валют (DCC)
— банк-эмитент установил ограничения на транзакции в данной валюте
— банк-эмитент установил ограничения на транзакции в данной стране
— банк-эмитент в США ограничил по карте операции в валюте, отличной от USD
— банк-эмитент в США ограничил по карте операции в странах бывшего СНГ и других рисковых регионах Банк-эмитент (банк, выпустивший карту). Если банк-эмитент не видит данную транзакцию, тогда необходимо обратиться в банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру

55

055

12

902

9882

9912

Invalid transaction

Invalid transaction card / issuer / acquirer

Decline reason message: invalid transaction

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

95

095

61

061

121

9861

9863

Decline, exceeds withdrawal amount limit

Exceeds amount limit

Exceeds withdrawal limit

Withdrawal limit would be exceeded

Withdrawal limit already reached

Card exceeds withdrawal amount limit На карте достигнут лимит по сумме операций в сутки, в месяц или на разовую транзакцию Возможные причины (более детально смотрите по банку-эквайеру выше):
— на карте не установлен лимит операций в интернет или он уже достигнут или будет достигнут с текущей транзакцией
— общий лимит по сумме для операций покупок по карте уже достигнут или будет достигнут с текущей транзакцией
— карта не открыта для расчетов в интернет
— на карте не активирован сервис 3D-Secure из-за чего операции в интернет без 3D-Secure пароля попадают под ограничения банка-эмитента Банк-эмитент (банк, выпустивший карту)

65

065

82

082

9860

Activity count exceeded

Exceeds frequency limit

Maximum number of times used

Card exceeds withdrawal frequency limit На карте достигнут лимит по количеству операций в сутки или в месяц Возможные причины (более детально смотрите по банку-эквайеру выше):
— на карте не установлен лимит операций в интернет или он уже достигнут или будет достигнут с текущей транзакцией
— общий лимит по количеству операций покупок по карте уже достигнут или будет достигнут с текущей транзакцией
— карта не открыта для расчетов в интернет
— на карте не активирован сервис 3D-Secure из-за чего операции в интернет без 3D-Secure пароля попадают под ограничения банка-эмитента Банк-эмитент (банк, выпустивший карту)

57

119

Not permitted to client

Transaction not permitted on card

Transaction not permitted to card

Decline, transaction not permitted to cardholder

Transaction not permitted to card

Not permitted to client

Decline, transaction not permitted to cardholder

Function Not Permitted To Cardholder

Not permitted to client Транзакция не разрешена для карты или клиента

Банк эмитент отклонил транзакцию так как она не может быть осуществлена для этой карты или клиента.

Возможные причины (более детально смотрите по банку-эквайеру выше):
— данный карточный продукт не рассчитан для такого типа операции
— для данной карты не настроен такой тип операции на стороне банка-эмитента

Банк-эмитент (банк, выпустивший карту)

58

120

Decline, transaction not permitted to terminal

Not permitted to merchant

The requested service is not permitted for terminal

Function Not Permitted To Terminal

Txn Not Permitted On Term

Not permitted to merchant Транзакция не разрешена для терминала или мерчанта Мерчант или терминал настроен некорректно, или данный тип операции не разрешен на стороне банка-эквайера или платежного провайдера. В первую очередь нужно уточнить конфигурацию торговой точки у платежного провайдера и список допустимых операций Банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру

211

N7

9881

Bad CVV2

Decline for CVV2 Failure

CVV2 is invalid

Invalid CVV2

Decline Cvv2 failure

Invalid CVV2 code Введен неверный CVV2 код во время проведения платежа Необходимо проверить CVV2 код на оборотной стороне карты. Код состоит из 3 цифр для Visa/MasterCard/Discover и из 4 цифр для карт American Express.
CVV2 код также может называться CVC2, CID, CSC2 код.
В некоторых случаях такой код отказа может возвращаться и при вводе неверного срока действия карты.
Стоит обратить внимание, если банк эмитент использует динамический код CVV2, генерируемый на короткий промежуток времени в клиент-банке — срок жизни такого CVV2 кода мог истечь на момент совершения операции Банк-эмитент (банк, выпустивший карту)

058

59

059

62

062

9858

104

Restricted card

Restricted status

Decline, restricted card

Card is restricted

Your card is restricted

Restricted Card Операции по карте ограничены Возможные причины:
— операции по карте в данном регионе/стране не разрешены
— на карте установлен статус, ограничивающий платежи
— для карты не доступны интернет-платежи Банк-эмитент (банк, выпустивший карту)

56

056

Transaction not supported by institution Your card is not supported. Please use card of other payment system Данный тип платежной системы не поддерживается Банк-эквайер или платежный провайдер не поддерживает платежную систему данной карты.
Отказ может возникать в таких случаях:
— оплата картой локальной платежной системы за рубежом. Например картой платежной системы МИР за пределами РФ, картой платежной системы ПРОСТИР за пределами Украины
— оплата картами оплата AMERICAN EXPRESS, Diners Club,JCB, China Union Pay, Discover которые не поддерживаются платежным провайдером
— оплата картой Monobank в счет микро-кредитной организации (погашение кредита), либо выдача кредит. Монобанк блокирует операции в адрес МФО по некоторым типам карт Банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру
Монобанк, если карта этого банка

100

1000

Decline (general, no comments)

General decline, no comments

General decline

General decline Общий отказ. Причины могут быть теми же, что и для Do not honor Банк-эмитент (банк, выпустивший карту)

54

101

Expired card

Decline, expired card

Expired card

Pick-up, expired card

Card expired

Invalid card expiry date Истек срок действия карты Возможные причины
— срок действия карты закончился
— указан неверный срок действия карты
— карта была перевыпущена с новым сроком Банк-эмитент (банк, выпустивший карту)

14

111

9852

1012

305113

Card number does not exist

Invalid card number

No such card

Decline, card not effective

Invalid card

Wrong card number

Invalid card number Неверный номер карты Возможные причины:
— неверный номер карты
— карта не действительна
— оплата картой локальной платежной системы за рубежом. Например картой платежной системы МИР за пределами РФ, картой платежной системы ПРОСТИР за пределами Украины
— оплата картами оплата AMERICAN EXPRESS, Diners Club,JCB, China Union Pay, Discover которые не поддерживаются платежным провайдером
— операции по карте в данном регионе/стране не разрешены
— на карте установлен статус, ограничивающий платежи Банк-эмитент (банк, выпустивший карту)

909

42

7

07

108

9875

207

42

External Decline Special Condition

Special Pickup

Pick up card (special)

Pick up card, special condition (fraud account)

Pick-up, special conditions

Decline, refer to card issuer’s special conditions

Pick up card, special condition (fraud account) Специальный отказ банка-эмитента. Владелец карты подозревается в мошенничестве. Банк-эмитент подозревает держателя карты в мошенничестве, либо система безопасности (антифрод-система) банка эмитента отклонила транзакцию Банк-эмитент (банк, выпустивший карту)

122

63

89

Decline, security violation

Security violation

Security violation Отказ по соображениям безопасности Код отказа может отдаваться как банком-эмитентом, так и банком-эквайером. Возможные причины:
— карточный счет заморожен или заблокирован
— ограничения правил безопасности (система Antifraud на стороне любого из участников) Банк-эмитент (банк, выпустивший карту)
Банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру

200

76

114

21

Invalid account

Decline, no account of type requested

No To Account

Invalid card number Неверный номер карты или счета Возможные причины:
— счет карты закрыт или заблокирован
— по счету запрещены расходные операции
— карта не действительна
— неверный номер карты
— оплата картой локальной платежной системы за рубежом. Например картой платежной системы МИР за пределами РФ, картой платежной системы ПРОСТИР за пределами Украины
— оплата картами оплата AMERICAN EXPRESS, Diners Club,JCB, China Union Pay, Discover которые не поддерживаются платежным провайдером
— операции по карте в данном регионе/стране не разрешены
— на карте установлен статус, ограничивающий платежи
— карта не предназначена для расчетов в интернет Банк-эмитент (банк, выпустивший карту)

74

074

907

911

910

9872

91

291

82

908

810

Unable to authorize

Decline reason message: card issuer or switch inoperative

Destination not available

Issuer or switch inoperative

Issuer unavailable

Time-out at issuer

Decline reason message: card issuer timed out

Decline reason message: transaction destination cannot be found for routing

Transaction timeout

Acquiring bank request timeout

Ошибка связи: таймаут

Недоступен эмитент/эквайер

Таймаут при попытке связи с банком-эмитентом. Как правило такая ошибка возникает при проблемах технического характера на стороне любого из участников: банка-эквайера, банка эмитента, платежной системы Visa/MasterCard/МИР.

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

Банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру

Банк-эмитент (при получении 91 кода)

15

815

92

No such card/issuer

No such issuer

Invalid Issuer

Invalid card number Указан неверный номер карты см. Неверный номер карты

811

96

0

System error Unknown payment system error Технический сбой на стороне эквайера/платежной системы Технический сбой на стороне банка-эквайера Банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру

4

04

44

43

200

104

Pick-up (general, no comments)

Pick up card

Your card is restricted

Hot Card, Pickup (if possible)

Hold — Pick up card

Pick-up, restricted card

Pick-up, card acceptor contact card acquirer

Pick up card (no fraud) Изъять карту Банк-эмитент отклонил транзакцию с сообщением о необходимости изъять карту, если это возможно. Как правило причиной является блокировка карты по причине утери Банк-эмитент (банк, выпустивший карту) 52 Number of PIN tries exceeded PIN tries exceeded Превышен лимит попыток ввода PIN-кода На карте установлен статус в связи с превышением попыток ввода PIN-кода при оплате в наземных POS-терминалах или использования карты в банкомате.
Также причиной может быть то, что карта только что выпущена и первой операцией для нее должна быть операция смены PIN-кода Банк-эмитент (банк, выпустивший карту)

205

110

13

567

9913

9867

Invalid advance amount

Decline, invalid amount

Invalid amount

Invalid amount Неверная сумма Причины отказа:
— слишком маленькая сумма. Если карта открыта в валюте, убедитесь, что сумма транзакции не менее 1 цента доллара США или 1 Евро цента
— слишком большая сумма
— из суммы транзакции невозможно удержать сумму комиссии платежного провайдера. Убедитесь, что сумма транзакции не меньше суммы всех комиссий
— ограничения на карте плательщика на стороне банка, который выпуcтил карту.
— достигнуты лимиты на стороне банка-эквайера. Банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру, Банк-эмитент (банк, выпустивший карту)

948

102

202

9934

59

Suspected fraud

Decline, suspected fraud

Suspected fraud Подозрение в мошенничестве Система безопасности одного из участников процессинговой цепочки подозревает участие карты в мошеннических действиях или в компрометации.
Также, возможно, что банк-эмитент заблокировал карту/счет в связи с подозрительными действиями, скиммингом, компрометацией Банк-эмитент (банк, выпустивший карту)

800

904

30

030

9874

574

Format error

Decline reason message: format error

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

41

540

208

9840

Lost Card, Pickup

Pick up card (lost card)

Lost card

Lost card, pick-up

Pick-up, lost card

Lost card Карта утеряна На карте установлен статус утеряна по заявлению картодержателя. Банк-эмитент (банк, выпустивший карту)

93

124

Violation of law

Decline, violation of law

Suspected fraud Транзакция не может быть выполнена: нарушение закона Банк-эмитент отказал в осуществлении транзакции во избежание нарушения закона Банк-эмитент (банк, выпустивший карту)

909

96

Decline reason message: system malfunction

System malfunction

System malfunction Технический сбой на стороне эквайера/платежной системы Технический сбой на стороне банка-эквайера Банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру

01

02

107

108

Refer to card issuer

Decline, refer to card issuer

Decline, refer to card issuer special conditions

Refer to issuer

Decline, refer to card issuer Обратиться к банку-эмитенту Отказ банка-эмитента. Держатель карты должен обратиться в свой банк Банк-эмитент (банк, выпустивший карту) 201 Incorrect PIN Incorrect PIN Неверный PIN На карте установлен статус в связи с превышением попыток ввода PIN-кода при оплате в наземных POS-терминалах или использования карты в банкомате.
Также причиной может быть то, что карта только что выпущена и первой операцией для нее должна быть операция смены PIN-кода Банк-эмитент (банк, выпустивший карту) 210 Bad CAVV Do not honor Неверный CAVV Ошибка возникает при проверке 3DSecure на стороне банка-эмитента. Причиной может случить либо неверная настройка 3DSecure на карте, либо некорректная реализация Apple/Google Pay токенов на стороне платежной платформы, мерчанта или банка-эквайера Банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру

43

209

057

9841

Pick up card (stolen card)

Pick-up, stolen card

Stolen card

Stolen card, pick-up

Lost/Stolen

Lost or stolen card

Stolen card Карта украдена Банк-эмитент установил на карте статус «украдена» по обращению держателя карты Банк-эмитент (банк, выпустивший карту)

6000

106

Pre-authorizations are not allowed within this context.

Merchant is not allowed preauth

Preauth not allowed Операция предавторизации на разрешена для торговца Необходимо обратиться к платежному провайдеру или банку-эквайеру для активации двухстадийной оплаты перед пред-авторизацию/завершение (preauth/capture или prepurchase/completion или authorization/sale) Банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру

03

3

109

9903

20003

Invalid merchant

Decline, invalid merchant

Merchant is not configured correctly Мерчант настроен некорректно Необходимо обратиться к платежному провайдеру или банку-эквайеру для настройки или активации мерчанта или мерчант-аккаунта.
Также причиной может быть некорректно переданный идентификатор мерчанта в транзакции Банк-эквайер (банк, обслуживающий торговую точку) или к платежному провайдеру

На чтение 5 мин. Просмотров 1.3k. Опубликовано 14.08.2019

BCD

Ошибки BCD

Проблемы, возникающие с BCD и Microsoft Windows, включают:

• «Ошибка: BCD. «
• «Отсутствует файл BCD.»
• «Отсутствует файл BCD.»
• «Сбой загрузки: BCD. «
• «Ошибка регистрации BCD. «
• «Ошибка выполнения: BCD.»
• «Файл BCD не может быть загружен. «

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

Истоки проблем BCD

Эти проблемы BCD создаются отсутствующими или поврежденными файлами BCD, недопустимыми записями реестра Microsoft Windows или вредоносным программным обеспечением.

В основном, осложнения BCD из-за:

• Раздел реестра BCD поврежден.
• Вредоносные программы заражены и повреждены BCD.
• BCD ошибочно удален или злонамеренно программным обеспечением, не связанным с приложением Microsoft Windows.
• Другое приложение, конфликтующее с BCD или другими общими ссылками.
• Загрузите повреждение или неполную установку программы, связанной с BCD.

Новая ОС Windows 10 от компании Microsoft уже завоевала популярность среди миллионов пользователей ПК во всем мире. Но, как и все новые продукты, Windows 10 не лишена изъянов. У многих пользователей этой ОС наблюдаются проблемы с загрузчиком. Наиболее часто такая проблема происходит из-за новой политики обновления операционной системы.

Сейчас в Windows 10 нельзя отключить обновления, как это было в Windows 7 и XP.

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

После того, как пользователь снова включает компьютер, он встречает такое сообщение на экране своего монитора.

Это сообщение говорит о том, что у вас поврежден загрузчик и его следует восстановить. Также стоит отметить, что выключение компьютера при обновлении не единственная причина поломки. Повредить загрузчик еще могут вирусы и различное вредоносное ПО. Еще довольно распространенными причинами его поломки являются неисправные HDD, в которых есть битые сектора, то есть загрузочная запись будет находиться именно на этих секторах. Также причиной поломки загрузчика может быть установка младшей ОС поверх Windows 10. Чтобы помочь нашим читателям восстановить загрузчик ниже мы подготовили примеры, в которых подробно опишем способы его восстановления.

Самый простой способ восстановления

Увидев сообщение о неисправности загрузчика, первым делом у пользователя ПК возникает вопрос — как восстановить загрузчик Windows 10. В этом примере мы опишем самый простой способ его восстановления. Для этого примера нам понадобится диск восстановления Windows 10.

Если у вас нет этого диска и доступа в Интернет, то можете сделать его на другом компьютере с этой же ОС.

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

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

В этом окне мы выберем вторую вкладку «Поиск и устранение неисправностей» и сразу перейдем на следующую «Дополнительные параметры».

В дополнительных параметрах нас интересует вкладка «Восстановление при загрузке». После перехода по этой ссылке мастер попросит выбрать ОС для восстановления ее запуска.

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

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

Для этого способа нам также потребуется диск восстановления Windows 10. Загрузимся с диска, как и в предыдущем примере до пункта «Дополнительные параметры». В этом меню нас интересует вкладка «Командная строка», по которой мы и перейдем.

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

Эта утилита необходима нам для вывода информации обо всех локальных дисках в системе. Теперь нам нужно найти номер раздела загрузчика. Обычно это скрытый раздел, занимающий 500 МБ. Создается этот раздел автоматически инсталлятором Windows 10. Далее для его поиска в DiskPart мы введем команду list volume

Из изображения видно, что раздел с загрузочной записью находится в первом томе на диске C. Также на изображении видно, что сама Windows 10 установлена на диск D. Теперь мы должны выйти из дисковой программы. Сделать это можно командой exit

После выхода из DiskPart введем команду bcdboot.exe D:Windows Также обратите внимание, что в команде используется диск D, так как именно на него установлена десятка.

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

Восстановление загрузчика Windows 10 с помощью командной строки (Способ второй)

Во втором способе мы также воспользуемся утилитами DiskPart и BCDboot и попробуем перезаписать загрузчик. Для этого запустим DiskPart и узнаем, на каком диске находится наш скрытый раздел и раздел, на котором установлена Windows 10. Запуск этой утилиты описан выше.

Теперь нам нужно отформатировать скрытый раздел, который находиться в первом томе. Для этого наберем команду select volume 1 которая выберет наш скрытый зашифрованный раздел размером в 500 МБ.

Дальнейшим действием будет форматирование выбранного раздела. Это делается для того, чтобы стереть все файлы с него. Для этой операции введем команду в консоли format fs=FAT32

После форматирования нашего раздела выйдем из дисковой утилиты и введем новую команду bcdboot.exe D:Windows которую вводили в предыдущем примере.

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

Еще один способ восстановления загрузки Windows 10 с помощью командной строки

Для этого способа нужна утилита Bootrec. В отличие от предыдущей утилиты эта утилита не восстанавливает файлы загрузчика, а восстанавливает загрузочную запись. То есть она восстанавливает MBR — первый сектор на HDD. Для операционной системы очень важно, чтобы MBR был в целости и сохранности. При старте компьютера его BIOS первым делом ищет MBR для осуществления с него запуска операционной системы. Для этого примера запустим, как и в предыдущих примерах, командную строку. В рассматриваемой утилите есть две основные команды /FixMbr и /FixBoot Первая команда необходима для исправления MBR, а вторая создает новый. Первым делом рассмотрим ситуацию, когда у нас поврежден MBR. Для этого в консоли введем первую команду.

На изображении выше видно, что операция прошла успешно, а это значит, что MBR восстановлен.

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

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

Из примеров видно, как легко восстановить сектор MBR с помощью консольной утилиты Bootrec. Если у вас проблема со стартом Windows 10, то советуем воспользоваться этим примером в первую очередь.

Чистим систему от вредоносного программного обеспечения до восстановления загрузчика

Если причиной поломки загрузчика является вредоносная программа, то этот вредоносный код необходимо удалить до восстановления. В этой ситуации вам поможет Dr.Web LiveDisk. Это аварийный диск, который обладает множеством средств для восстановления компьютера, а также лечения его от вирусов. Загрузить Dr.Web LiveDisk можно на его официальном сайте www.drweb.ru. Этот Live CD основан на linux и является бесплатным. Этот диск распространяется как образ ISO, который можно записать, как на оптический диск, так и на USB-флешку. После записи образа на диск запустим Dr.Web LiveDisk.

В стартовом меню выберем первый пункт и продолжим загрузку Dr.Web LiveDisk. После нескольких секунд должна запуститься ОС, основанная на Linux, которая собственно и представляет собой Dr.Web LiveDisk.

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

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

Подводим итог

В заключение хочется сказать, если вы будете знать все тонкости восстановления загрузчика, то вы сможете быстро починить свой компьютер. Также стоит обратить внимание на ситуацию, когда восстановить загрузочный сектор и сам загрузчик невозможно. В этом случае надо перестраховаться и воспользоваться средствами полного восстановления системы. Такими средствами являются полной образ системы, создающийся средствами самой ОС Windows 10, а также такая программа, как Acronis True Image. Надеемся, что наш материал поможет вам восстановить загрузчик с MBR, и компьютер будет функционировать, как и прежде.

Видео по теме

Хорошая реклама

Если после установки второй ОС, попыток воспользоваться свободным местом на скрытых разделах диска или их форматирования, в случае системных сбоев, при экспериментах с EasyBCD и в других случаях вы столкнулись с тем, что Windows 10 не загружается, сообщая «An operating system wasn’t found», «No bootable device found. Insert boot disk and press any key», то, возможно, вам требуется восстановление загрузчика Windows 10, о чем и пойдет речь ниже.

Вне зависимости от того, UEFI у вас или BIOS, установлена ли система на GPT диск со скрытым FAT32 разделом EFI загрузки или на MBR с разделом «Зарезервировано системой», действия по восстановлению будут одинаковыми для большинства ситуаций. Если ничто из нижеописанного не помогает, попробуйте Сброс Windows 10 с сохранением данных (третьим способом).

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

Автоматическое восстановление загрузчика

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

1. Загрузитесь с диска восстановления Windows 10 или загрузочной флешки с Windows 10 в той же разрядности, что и ваша система (диска). Для выбора накопителя для загрузки можно использовать Boot Menu.
2. В случае загрузки с установочного накопителя, на экране после выбора языка внизу слева нажмите пункт Восстановление системы. 
3. Выберите пункт Поиск и устранение неисправностей, а затем — Восстановление при загрузке. Выберите целевую операционную систему. Дальнейший процесс будет произведен автоматически. 

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

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

Процедура восстановления вручную

Для восстановления загрузчика вам потребуется либо дистрибутив Windows 10 (загрузочная флешка или диск), либо диск восстановления Windows 10. Если вы ими не обзавелись, придется воспользоваться другим компьютером для их создания. Подробнее о том, как сделать диск восстановления можно прочитать в статье Восстановление Windows 10.

Следующий этап — загрузиться с указанного носителя, поставив загрузку с него в БИОС (UEFI), либо используя Boot Menu. После загрузки, если это установочная флешка или диск, на экране выбора языка нажмите клавиши Shift + F10 (откроется командная строка). Если это диск восстановления в меню выберите Диагностика — Дополнительные параметры — Командная строка.

В командной строке введите по порядку три команды (после каждой нажимаем Enter):

1. diskpart
2. list volume
3. exit

В результате выполнения команды list volume, вы увидите список подключенных томов. Запомните букву того тома, на котором располагаются файлы Windows 10 (в процессе восстановления это может быть не раздел C, а раздел под какой-либо другой буквой).

В большинстве случаев (на компьютере только одна ОС Windows 10, скрытый раздел EFI или MBR в наличии), для того, чтобы восстановить загрузчик, достаточно после этого выполнить одну команду:

bcdboot c:windows (где вместо C может потребоваться указать другую букву, о чем было сказано выше).

Примечание: если на компьютере несколько ОС, например, Windows 10 и 8.1, вы можете выполнить эту команду дважды, в первом случае указав путь к файлам одной ОС, во втором — другой (не сработает для Linux и XP. Для 7-ки зависит от конфигурации).

После выполнения этой команды вы увидите сообщение о том, что файлы загрузки успешно созданы. Можно попробовать перезагрузить компьютер в обычном режиме (вынув загрузочную флешку или диск) и проверить, загружается ли система (после некоторых сбоев загрузка происходит не сразу после восстановления загрузчика, а после проверки HDD или SSD и перезагрузки, также может проявиться ошибка 0xc0000001, которая в этом случае также обычно исправляется простой перезагрузкой).

Второй способ восстановить загрузчик Windows 10

Если вышеописанный способ не сработал, то возвращаемся в командную строку так же, как делали это ранее. Вводим команды diskpart, а потом — list volume. И изучаем подключенные разделы дисков.

Если у вас система с UEFI и GPT, в списке вы должны увидеть скрытый раздел с файловой системой FAT32 и размером 99-300 Мб. Если же BIOS и MBR, то должен обнаружиться раздел размером 500 Мб (после чистой установки Windows 10) или меньше с файловой системой NTFS. Вам требуется номер этого раздела N (Том 0, Том 1 и т.д.). Также обратите внимание на букву, соответствующую разделу, на котором хранятся файлы Windows.

Введите по порядку следующие команды:

1. select volume N
2. format fs=fat32 или format fs=ntfs (в зависимости от того, какая файловая система на разделе).
3. assign letter=Z (присваиваем букву Z этому разделу).
4. exit (выходим из Diskpart)
5. bcdboot C:Windows /s Z: /f ALL (где C: — диск с файлами Windows, Z: — буква, которую мы присвоили скрытому разделу).
6. Если у вас несколько ОС Windows, повторите команду для второй копии (с новым расположением файлов).
7. diskpart
8. list volume
9. select volume N (номер скрытого тома, которому мы присваивали букву)
10. remove letter=Z (удаляем букву, чтобы том не отображался в системе, когда мы перезагрузимся).
11. exit

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

Надеюсь, изложенная информация сможет вам помочь. Кстати, можно попробовать также и «Восстановление при загрузке» в дополнительных параметрах загрузки или с диска восстановления Windows 10. К сожалению, не всегда все проходит гладко, и проблема легко решается: часто (при отсутствии повреждений HDD, что тоже может быть) приходится прибегать к переустановке ОС.

Обновление (пришло в комментариях, а я что-то о способе забыл в статье написать): также можно попробовать простую команду bootrec.exe /fixboot (см. Использование bootrec.exe для исправления загрузочных записей).

При установке на компьютер второй ОС или работе с приложениями, отвечающими за настройку конфигурации загрузки Window 10, нужно быть предельно внимательным и аккуратным. Всего одно неправильное действие может привести к тому, что система перестанет загружаться, и вы получите ошибку «An operating system wasn’t found» или «The boot configuration data for your PC is missing».

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

Использование средств самой Windows

Самый простой способ восстановить загрузчик Windows 10 – это прибегнуть к помощи штатных инструментов диагностики и ремонта, запущенных из среды восстановления. В случае с «десяткой» в среду восстановления вы попадете после трех неудачных загрузок, но всё же будет лучше воспользоваться для входа в нее установочным диском с ОС. Загрузитесь с носителя, содержащего дистрибутив Виндовс 10, и нажмите «Далее», а затем «Восстановление системы» в окне мастера-установщика.

Проследуйте по указанной на скриншотах цепочке опций.

Далее нажмите «Восстановление при загрузке», выберите свою ОС и предоставьте Windows возможность сделать свою работу.

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

Увы, чаще всего так и бывает, ибо встроенное в WinPE средство устранения неполадок способно справляться только с типичными проблемами. Но не беда, на этот случай есть более эффективные методы.

Консольная утилита bcdboot

Восстановление загрузчика Windows 10 можно выполнить и через командную строку, загрузившись предварительно с установочного диска. При появлении на экране мастера-установщика откройте консоль нажатием Shift+F10 и с помощью команд explorer или diskpart – list volume определите букву системного тома. Команда explorer открывает Проводник, diskpart – list volume выводит список томов непосредственно в консоли. Определив букву (в нашем примере это E), вводом exit завершите работу diskpart (если использовался этот инструмент) и выполните команду восстановления загрузчика:

bcdboot E:/windows

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

Проблемы с загрузкой Windows 10 иногда бывают вызваны повреждением самой загрузочной записи. Чтобы ее восстановить, перейдите в расположение System32 и последовательно выполните в запущенной из-под установочного диска консоли приведенные ниже команды. Выглядит это так:

cd x:/windows/system32bootrec /fixmbrbootrec /fixboot

В системах UEFI

Описанный выше способ применим к ПК на базе обычного BIOS с дисками MBR, тогда как процедура восстановления загрузчика в системах UEFI несколько отличается. Выполнить все действия здесь можно в той же командной строке, но есть и более простой способ. Воспользуйтесь спасательным диском by Sergei Strelec, ведь в нём имеются все необходимые инструменты для устранения подобного рода неполадок. Загрузив с диска компьютер, перейдите в меню Пуск по цепочке Программы WinPE – Редакторы BCD – EasyUEFI.

В открывшемся окне утилиты выберите опции Manage EFI System Partition – Rebuild EFI System Partition.

Далее укажите диск, на котором нужно восстановить загрузчик, а потом активируйте радиокнопки для системного (с файлами Windows) и служебного EFI-раздела. На заключительном этапе нажмите «Rebuild», закройте приложение и перезагрузите компьютер в штатном режиме.

Если EasyUEFI не справится с задачей, используйте командную строку, предварительно присвоив EFI-тому букву с помощью входящей в состав диска от Стрельца утилиты Bootice. Запустите ее из того же меню, что и EasyUEFI, выберите в окошке ваш жесткий диск и нажмите «Parts Manage».

В открывшейся таблице выберите EFI-раздел (он отформатирован в FAT32 и традиционно имеет размер около 100 Мб), после чего нажатием кнопки «Assign Drive Letter» присвойте ему любую незанятую букву.

Закрыв EasyUEFI, запустите командную строку и выполните две этих команды:

cd /d БУКВА:/efi/microsoft/bootbootrec /rebuildbcd

В результате вы получите список установленных Windows и приглашение внести их в загрузочный реестр. Подтверждаем операцию вводом буквы Y и нажатием Enter. Готово, можете загрузить компьютер в обычном режиме.

Если вдруг загрузка окажется неудачной, и вместо логотипа Windows вы увидите экран BSOD, нажмите сначала F8, а затем Enter, чтобы перезапустить процедуру загрузки.

К слову, диск by Sergei Strelec можно использовать и для восстановления загрузчика на MBR-дисках. Для этого вместо EasyUEFI запускам утилиту EasyBCD, переключаемся в меню «Архивация/Восстановление», отмечаем «Обновить файлы загрузки» и жмем кнопку «Выполнить».

Итог

Восстановление загрузчика Windows 10, как мы видим, вполне решаемая задача, но давайте все-таки допустим, что ни один из этих способов не помог. В этом случае вместо напрашивающейся переустановки захватите с помощью входящей в состав диска by Sergei Strelec утилиты Dism++ Windows в WIM-образ, а затем, полностью удалив все системные разделы, выполните его повторную установку, в процессе которой все служебные разделы с загрузчиками и прочими файлами будут пересозданы с нуля. Такой способ является наиболее эффективным после переустановки или восстановления из полного бэкапа. Но сработает он только при условии, что созданный WIM-образ сам не содержит ошибки, препятствующие нормальной загрузке Windows.

Используемые источники:

• https://ustanovkaos.ru/reshenie-problem/vosstanovlenie-zagruzchika-windows-10.html
• https://remontka.pro/windows-10-bootloader-fix/
• https://viarum.ru/kak-vosstanovit-zagruzchik-windows-10/

Привет! Представляю вашему вниманию перевод статьи «Error and Transaction Handling in SQL Server. Part One – Jumpstart Error Handling» автора Erland Sommarskog.

1. Введение

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

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

Все статьи описывают обработку ошибок и транзакций в SQL Server для версии 2005 и более поздних версий.

1.1 Зачем нужна обработка ошибок?

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

Мы часто хотим, чтобы в базе данных изменения были атомарными. Например, задача по переводу денег с одного счета на другой. С этой целью мы должны изменить две записи в таблице CashHoldings и добавить две записи в таблицу Transactions. Абсолютно недопустимо, чтобы ошибки или сбой привели к тому, что деньги будут переведены на счет получателя, а со счета отправителя они не будут списаны. По этой причине обработка ошибок также касается и обработки транзакций. В приведенном примере нам нужно обернуть операцию в BEGIN TRANSACTION и COMMIT TRANSACTION, но не только это: в случае ошибки мы должны убедиться, что транзакция откачена.

2. Основные команды

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

2.1 TRY-CATCH

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

BEGIN TRY
   <обычный код>
END TRY
BEGIN CATCH
   <обработка ошибок>
END CATCH

Если какая-либо ошибка появится в <обычный код>, выполнение будет переведено в блок CATCH, и будет выполнен код обработки ошибок.

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

Вот очень быстрый пример:

BEGIN TRY
   DECLARE @x int
   SELECT @x = 1/0
   PRINT 'Not reached'
END TRY
BEGIN CATCH 
   PRINT 'This is the error: ' + error_message()
END CATCH

Результат выполнения: This is the error: Divide by zero error encountered.

Мы вернемся к функции error_message() позднее. Стоит отметить, что использование PRINT в обработчике CATCH приводится только в рамках экспериментов и не следует делать так в коде реального приложения.

Если <обычный код> вызывает хранимую процедуру или запускает триггеры, то любая ошибка, которая в них возникнет, передаст выполнение в блок CATCH. Если более точно, то, когда возникает ошибка, SQL Server раскручивает стек до тех пор, пока не найдёт обработчик CATCH. И если такого обработчика нет, SQL Server отправляет сообщение об ошибке напрямую клиенту.

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

CREATE PROCEDURE inner_sp AS
   BEGIN TRY
      PRINT 'This prints'
      SELECT * FROM NoSuchTable
      PRINT 'This does not print'
   END TRY
   BEGIN CATCH
      PRINT 'And nor does this print'
   END CATCH
go
EXEC inner_sp

Выходные данные:

This prints
Msg 208, Level 16, State 1, Procedure inner_sp, Line 4
Invalid object name 'NoSuchTable'

Как можно видеть, блок TRY присутствует, но при возникновении ошибки выполнение не передается блоку CATCH, как это ожидалось. Это применимо ко всем ошибкам компиляции, таким как пропуск колонок, некорректные псевдонимы и тому подобное, которые возникают во время выполнения. (Ошибки компиляции могут возникнуть в SQL Server во время выполнения из-за отложенного разрешения имен – особенность, благодаря которой SQL Server позволяет создать процедуру, которая обращается к несуществующим таблицам.)

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

CREATE PROCEDURE outer_sp AS
   BEGIN TRY
      EXEC inner_sp
   END TRY
   BEGIN CATCH
      PRINT 'The error message is: ' + error_message()
   END CATCH
go
EXEC outer_sp

Теперь мы получим на выходе это:

This prints
The error message is: Invalid object name 'NoSuchTable'.

На этот раз ошибка была перехвачена, потому что сработал внешний обработчик CATCH.

2.2 SET XACT_ABORT ON

В начало ваших хранимых процедур следует всегда добавлять это выражение:

SET XACT_ABORT, NOCOUNT ON

Оно активирует два параметра сессии, которые выключены по умолчанию в целях совместимости с предыдущими версиями, но опыт доказывает, что лучший подход – это иметь эти параметры всегда включенными. Поведение SQL Server по умолчанию в той ситуации, когда не используется TRY-CATCH, заключается в том, что некоторые ошибки прерывают выполнение и откатывают любые открытые транзакции, в то время как с другими ошибками выполнение последующих инструкций продолжается. Когда вы включаете XACT_ABORT ON, почти все ошибки начинают вызывать одинаковый эффект: любая открытая транзакция откатывается, и выполнение кода прерывается. Есть несколько исключений, среди которых наиболее заметным является выражение RAISERROR.

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

Для надежной обработки ошибок в SQL Server вам необходимы как TRY-CATCH, так и SET XACT_ABORT ON. Среди них инструкция SET XACT_ABORT ON наиболее важна. Если для кода на промышленной среде только на нее полагаться не стоит, то для быстрых и простых решений она вполне подходит.

Параметр NOCOUNT не имеет к обработке ошибок никакого отношения, но включение его в код является хорошей практикой. NOCOUNT подавляет сообщения вида (1 row(s) affected), которые вы можете видеть в панели Message в SQL Server Management Studio. В то время как эти сообщения могут быть полезны при работе c SSMS, они могут негативно повлиять на производительность в приложении, так как увеличивают сетевой трафик. Сообщение о количестве строк также может привести к ошибке в плохо написанных клиентских приложениях, которые могут подумать, что это данные, которые вернул запрос.

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

SET NOCOUNT ON
SET XACT_ABORT ON

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

3. Основной пример обработки ошибок

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

Для примера я буду использовать эту простую таблицу.

CREATE TABLE sometable(a int NOT NULL,
                       b int NOT NULL,
                       CONSTRAINT pk_sometable PRIMARY KEY(a, b))

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

CREATE PROCEDURE insert_data @a int, @b int AS 
   SET XACT_ABORT, NOCOUNT ON
   BEGIN TRY
      BEGIN TRANSACTION
      INSERT sometable(a, b) VALUES (@a, @b)
      INSERT sometable(a, b) VALUES (@b, @a)
      COMMIT TRANSACTION
   END TRY
   BEGIN CATCH
      IF @@trancount > 0 ROLLBACK TRANSACTION
      DECLARE @msg nvarchar(2048) = error_message()  
      RAISERROR (@msg, 16, 1)
      RETURN 55555
   END CATCH

Первая строка в процедуре включает XACT_ABORT и NOCOUNT в одном выражении, как я показывал выше. Эта строка – единственная перед BEGIN TRY. Все остальное в процедуре должно располагаться после BEGIN TRY: объявление переменных, создание временных таблиц, табличных переменных, всё. Даже если у вас есть другие SET-команды в процедуре (хотя причины для этого встречаются редко), они должны идти после BEGIN TRY.

Причина, по которой я предпочитаю указывать SET XACT_ABORT и NOCOUNT перед BEGIN TRY, заключается в том, что я рассматриваю это как одну строку шума: она всегда должна быть там, но я не хочу, чтобы это мешало взгляду. Конечно же, это дело вкуса, и если вы предпочитаете ставить SET-команды после BEGIN TRY, ничего страшного. Важно то, что вам не следует ставить что-либо другое перед BEGIN TRY.

Часть между BEGIN TRY и END TRY является основной составляющей процедуры. Поскольку я хотел использовать транзакцию, определенную пользователем, я ввел довольно надуманное бизнес-правило, в котором говорится, что если вы вставляете пару, то обратная пара также должна быть вставлена. Два выражения INSERT находятся внутри BEGIN и COMMIT TRANSACTION. Во многих случаях у вас будет много строк кода между BEGIN TRY и BEGIN TRANSACTION. Иногда у вас также будет код между COMMIT TRANSACTION и END TRY, хотя обычно это только финальный SELECT, возвращающий данные или присваивающий значения выходным параметрам. Если ваша процедура не выполняет каких-либо изменений или имеет только одно выражение INSERT/UPDATE/DELETE/MERGE, то обычно вам вообще не нужно явно указывать транзакцию.

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

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

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

IF @@trancount > 0 ROLLBACK TRANSACTION

не нужна, если нет явной транзакции в процедуре, но это абсолютно неверно. Возможно, вы вызываете хранимую процедуру, которая открывает транзакцию, но которая не может ее откатить из-за ограничений TRY-CATCH. Возможно, вы или кто-то другой добавите явную транзакцию через два года. Вспомните ли вы тогда о том, что нужно добавить строку с откатом? Не рассчитывайте на это. Я также слышу читателей, которые возражают, что если тот, кто вызывает процедуру, открыл транзакцию, мы не должны ее откатывать… Нет, мы должны, и если вы хотите знать почему, вам нужно прочитать вторую и третью части. Откат транзакции в обработчике CATCH – это категорический императив, у которого нет исключений.

Код повторной генерации ошибки включает такую строку:

DECLARE @msg nvarchar(2048) = error_message()

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

Замечание: синтаксис для присвоения начального значения переменной в DECLARE был внедрен в SQL Server 2008. Если у вас SQL Server 2005, вам нужно разбить строку на DECLARE и выражение SELECT.

Финальное выражение RETURN – это страховка. RAISERROR никогда не прерывает выполнение, поэтому выполнение следующего выражения будет продолжено. Пока все процедуры используют TRY-CATCH, а также весь клиентский код обрабатывает исключения, нет повода для беспокойства. Но ваша процедура может быть вызвана из старого кода, написанного до SQL Server 2005 и до внедрения TRY-CATCH. В те времена лучшее, что мы могли делать, это смотреть на возвращаемые значения. То, что вы возвращаете с помощью RETURN, не имеет особого значения, если это не нулевое значение (ноль обычно обозначает успешное завершение работы).

Последнее выражение в процедуре – это END CATCH. Никогда не следует помещать какой-либо код после END CATCH. Кто-нибудь, читающий процедуру, может не увидеть этот кусок кода.

После прочтения теории давайте попробуем тестовый пример:

EXEC insert_data 9, NULL

Результат выполнения:

Msg 50000, Level 16, State 1, Procedure insert_data, Line 12
Cannot insert the value NULL into column 'b', table 'tempdb.dbo.sometable'; column does not allow nulls. INSERT fails.

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

CREATE PROCEDURE outer_sp @a int, @b int AS
   SET XACT_ABORT, NOCOUNT ON
   BEGIN TRY
      EXEC insert_data @a, @b
   END TRY
   BEGIN CATCH
      IF @@trancount > 0 ROLLBACK TRANSACTION
      DECLARE @msg nvarchar(2048) = error_message()
      RAISERROR (@msg, 16, 1)
      RETURN 55555
   END CATCH
go
EXEC outer_sp 8, 8

Результат работы:

Msg 50000, Level 16, State 1, Procedure outer_sp, Line 9
Violation of PRIMARY KEY constraint 'pk_sometable'. Cannot insert duplicate key in object 'dbo.sometable'. The duplicate key value is (8, 8).

Мы получили корректное сообщение об ошибке, но если вы посмотрите на заголовки этого сообщения и на предыдущее поближе, то можете заметить проблему:

Msg 50000, Level 16, State 1, Procedure insert_data, Line 12
Msg 50000, Level 16, State 1, Procedure outer_sp, Line 9

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

4. Три способа генерации ошибки

4.1 Использование error_handler_sp

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

Позвольте представить вам error_handler_sp:

CREATE PROCEDURE error_handler_sp AS
 
   DECLARE @errmsg   nvarchar(2048),
           @severity tinyint,
           @state    tinyint,
           @errno    int,
           @proc     sysname,
           @lineno   int
           
   SELECT @errmsg = error_message(), @severity = error_severity(),
          @state  = error_state(), @errno = error_number(),
          @proc   = error_procedure(), @lineno = error_line()
       
   IF @errmsg NOT LIKE '***%'
   BEGIN
      SELECT @errmsg = '*** ' + coalesce(quotename(@proc), '<dynamic SQL>') + 
                       ', Line ' + ltrim(str(@lineno)) + '. Errno ' + 
                       ltrim(str(@errno)) + ': ' + @errmsg
   END
   RAISERROR('%s', @severity, @state, @errmsg)

Первое из того, что делает error_handler_sp – это сохраняет значение всех error_xxx() функций в локальные переменные. Я вернусь к выражению IF через секунду. Вместо него давайте посмотрим на выражение SELECT внутри IF:

SELECT @errmsg = '*** ' + coalesce(quotename(@proc), '<dynamic SQL>') + 
                 ', Line ' + ltrim(str(@lineno)) + '. Errno ' + 
                 ltrim(str(@errno)) + ': ' + @errmsg

Цель этого SELECT заключается в форматировании сообщения об ошибке, которое передается в RAISERROR. Оно включает в себя всю информацию из оригинального сообщения об ошибке, которое мы не можем вставить напрямую в RAISERROR. Мы должны обработать имя процедуры, которое может быть NULL для ошибок в обычных скриптах или в динамическом SQL. Поэтому используется функция COALESCE. (Если вы не понимаете форму выражения RAISERROR, я рассказываю о нем более детально во второй части.)

Отформатированное сообщение об ошибке начинается с трех звездочек. Этим достигаются две цели: 1) Мы можем сразу видеть, что это сообщение вызвано из обработчика CATCH. 2) Это дает возможность для error_handler_sp отфильтровать ошибки, которые уже были сгенерированы один или более раз, с помощью условия NOT LIKE ‘***%’ для того, чтобы избежать изменения сообщения во второй раз.

Вот как обработчик CATCH должен выглядеть, когда вы используете error_handler_sp:

BEGIN CATCH
   IF @@trancount > 0 ROLLBACK TRANSACTION
   EXEC error_handler_sp
   RETURN 55555
END CATCH

Давайте попробуем несколько тестовых сценариев.

EXEC insert_data 8, NULL
EXEC outer_sp 8, 8

Результат выполнения:

Msg 50000, Level 16, State 2, Procedure error_handler_sp, Line 20
*** [insert_data], Line 5. Errno 515: Cannot insert the value NULL into column 'b', table 'tempdb.dbo.sometable'; column does not allow nulls. INSERT fails.
Msg 50000, Level 14, State 1, Procedure error_handler_sp, Line 20
*** [insert_data], Line 6. Errno 2627: Violation of PRIMARY KEY constraint 'pk_sometable'. Cannot insert duplicate key in object 'dbo.sometable'. The duplicate key value is (8, 8).

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

Я покажу еще два метода вызова ошибок. Однако error_handler_sp является моей главной рекомендацией для читателей, которые читают эту часть. Это — простой вариант, который работает на всех версиях SQL Server начиная с 2005. Существует только один недостаток: в некоторых случаях SQL Server генерирует два сообщения об ошибках, но функции error_xxx() возвращают только одну из них, и поэтому одно из сообщений теряется. Это может быть неудобно при работе с административными командами наподобие BACKUPRESTORE, но проблема редко возникает в коде, предназначенном чисто для приложений.

4.2. Использование ;THROW

В SQL Server 2012 Microsoft представил выражение ;THROW для более легкой обработки ошибок. К сожалению, Microsoft сделал серьезную ошибку при проектировании этой команды и создал опасную ловушку.

С выражением ;THROW вам не нужно никаких хранимых процедур. Ваш обработчик CATCH становится таким же простым, как этот:

BEGIN CATCH
   IF @@trancount > 0 ROLLBACK TRANSACTION
   ;THROW
   RETURN 55555
END CATCH

Достоинство ;THROW в том, что сообщение об ошибке генерируется точно таким же, как и оригинальное сообщение. Если изначально было два сообщения об ошибках, оба сообщения воспроизводятся, что делает это выражение еще привлекательнее. Как и со всеми другими сообщениями об ошибках, ошибки, сгенерированные ;THROW, могут быть перехвачены внешним обработчиком CATCH и воспроизведены. Если обработчика CATCH нет, выполнение прерывается, поэтому оператор RETURN в данном случае оказывается не нужным. (Я все еще рекомендую оставлять его, на случай, если вы измените свое отношение к ;THROW позже).

Если у вас SQL Server 2012 или более поздняя версия, измените определение insert_data и outer_sp и попробуйте выполнить тесты еще раз. Результат в этот раз будет такой:

Msg 515, Level 16, State 2, Procedure insert_data, Line 5
Cannot insert the value NULL into column 'b', table 'tempdb.dbo.sometable'; column does not allow nulls. INSERT fails.
Msg 2627, Level 14, State 1, Procedure insert_data, Line 6
Violation of PRIMARY KEY constraint 'pk_sometable'. Cannot insert duplicate key in object 'dbo.sometable'. The duplicate key value is (8, 8).

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

В этом месте вы можете сказать себе: действительно ли Microsoft назвал команду ;THROW? Разве это не просто THROW? На самом деле, если вы посмотрите в Books Online, там не будет точки с запятой. Но точка с запятой должны быть. Официально они отделяют предыдущее выражение, но это опционально, и далеко не все используют точку с запятой в выражениях T-SQL. Более важно, что если вы пропустите точку с запятой перед THROW, то не будет никакой синтаксической ошибки. Но это повлияет на поведение при выполнении выражения, и это поведение будет непостижимым для непосвященных. При наличии активной транзакции вы получите сообщение об ошибке, которое будет полностью отличаться от оригинального. И еще хуже, что при отсутствии активной транзакции ошибка будет тихо выведена без обработки. Такая вещь, как пропуск точки с запятой, не должно иметь таких абсурдных последствий. Для уменьшения риска такого поведения, всегда думайте о команде как о ;THROW (с точкой с запятой).

Нельзя отрицать того, что ;THROW имеет свои преимущества, но точка с запятой не единственная ловушка этой команды. Если вы хотите использовать ее, я призываю вас прочитать по крайней мере вторую часть этой серии, где я раскрываю больше деталей о команде ;THROW. До этого момента, используйте error_handler_sp.

4.3. Использование SqlEventLog

Третий способ обработки ошибок – это использование SqlEventLog, который я описываю очень детально в третьей части. Здесь я лишь сделаю короткий обзор.

SqlEventLog предоставляет хранимую процедуру slog.catchhandler_sp, которая работает так же, как и error_handler_sp: она использует функции error_xxx() для сбора информации и выводит сообщение об ошибке, сохраняя всю информацию о ней. Вдобавок к этому, она логирует ошибку в таблицу splog.sqleventlog. В зависимости от типа приложения, которое у вас есть, эта таблица может быть очень ценным объектом.

Для использования SqlEventLog, ваш обработчик CATCH должен быть таким:

BEGIN CATCH
   IF @@trancount > 0 ROLLBACK TRANSACTION
   EXEC slog.catchhandler_sp @@procid
   RETURN 55555
END CATCH

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

Msg 50000, Level 16, State 2, Procedure catchhandler_sp, Line 125
{515} Procedure insert_data, Line 5
Cannot insert the value NULL into column 'b', table 'tempdb.dbo.sometable'; column does not allow nulls. INSERT fails.
Msg 50000, Level 14, State 1, Procedure catchhandler_sp, Line 125
{2627} Procedure insert_data, Line 6
Violation of PRIMARY KEY constraint 'pk_sometable'. Cannot insert duplicate key in object 'dbo.sometable'. The duplicate key value is (8, 8).

Как вы видите, сообщение об ошибке отформатировано немного не так, как это делает error_handler_sp, но основная идея такая же. Вот образец того, что было записано в таблицу slog.sqleventlog:

Если вы хотите попробовать SqlEventLog, вы можете загрузить файл sqleventlog.zip. Инструкция по установке находится в третьей части, раздел Установка SqlEventLog.

5. Финальные замечания

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

1. Как мы видели, ошибки компиляции не могут быть перехвачены в той же процедуре, в которой они возникли, а только во внешней процедуре.
2. Пример не работает с пользовательскими функциями, так как ни TRY-CATCH, ни RAISERROR нельзя в них использовать.
3. Когда хранимая процедура на Linked Server вызывает ошибку, эта ошибка может миновать обработчик в хранимой процедуре на локальном сервере и отправиться напрямую клиенту.
4. Когда процедура вызвана как INSERT-EXEC, вы получите неприятную ошибку, потому что ROLLBACK TRANSACTION не допускается в данном случае.
5. Как упомянуто выше, если вы используете error_handler_sp или SqlEventLog, мы потеряете одно сообщение, когда SQL Server выдаст два сообщения для одной ошибки. При использовании ;THROW такой проблемы нет.

Я рассказываю об этих ситуациях более подробно в других статьях этой серии.

Перед тем как закончить, я хочу кратко коснуться триггеров и клиентского кода.

Триггеры

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

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

Клиентский код

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

Здесь я только обращу внимание на важную вещь: реакцией на ошибку, возвращенную SQL Server, должно быть завершение запроса во избежание открытых бесхозных транзакций:

IF @@trancount > 0 ROLLBACK TRANSACTION

Это также применимо к знаменитому сообщению Timeout expired (которое является не сообщением от SQL Server, а от API).

6. Конец первой части

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

… и не забывайте добавлять эту строку в начало ваших хранимых процедур:

SET XACT_ABORT, NOCOUNT ON

Автор: Schekotka

Источник

Основной вопрос: «Есть ли какая-нибудь утилита, которая может интерпретировать эти два двоичных файла:

1. BCD.LOG
2. BOOTSTAT.DAT

они оба обновлены в процессе загрузки Vista/W7?

Я уже знаю о EasyBCD, и я нашел эту страницу о формате BOOTSTAT.DAT, но я бы предпочел не изобретать велосипед заново.

Справочная информация

Я нахожусь в неудобном положении, когда мой родной раздел Windows 7 отказывается завершить процесс загрузки (даже в безопасном режиме с подсказкой).

Это произошло после успешной загрузки его из VirtualBox через доступ к необработанному устройству. На самом деле, загрузка VB работает стабильно хорошо. Однако каждый раз, когда я пытаюсь загрузиться, процесс загрузки пытается «восстановить» конфигурацию. В действительности снаружи он вращает диски целую вечность и в конечном итоге застопорился. Прежде чем я использую раздел PQService для возврата к заводской конфигурации (в любом случае, это новая машина), я хотел бы взглянуть на эти 2 файла, к которым я могу без проблем обращаться с диска Ubuntu.

Кроме того, если есть другие файлы, которые могут помочь в диагностике причины проблемы, пожалуйста, дайте мне знать. Например, winload.exe создает журнал (это второстепенный вопрос)?

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

Спасибо за помощь.