Состояние ошибки 6 Windows 10

Обновлено: 21.11.2024

Принтер с ошибкой — это буквально самое худшее, что может быть.

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

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

1. Убедитесь, что принтер правильно подключен к компьютеру

Первое, что нужно проверить, это подключение вашего принтера к компьютеру.

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

Если вы используете беспроводной принтер, вы должны подключить принтер к работающей сети Wi-Fi. Ему также должен быть назначен IP-адрес.

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

Введите панель управления в строке поиска меню "Пуск" и выберите наиболее подходящее.
На панели управления в разделе "Оборудование и звук" нажмите "Просмотр устройств и принтеров".
Теперь вы можете видеть установленные устройства на своем ПК. Найдите здесь свой принтер и выберите его.
На нижней панели в поле «Состояние» вашего принтера должно быть указано «Готово». Это означает, что ваш компьютер распознает принтер и может взаимодействовать с ним.

2. Перезагрузите принтер

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

На большинстве принтеров это можно сделать, нажав кнопку питания на самом принтере. Затем подождите примерно полминуты и снова нажмите кнопку питания.

Ваш компьютер больше не должен отображать сообщение об ошибке.

3. Проверка уровня чернил в бумаге и картридже

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

Технически это проблема вашего принтера, а не компьютера.

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

4. Переустановите драйверы принтера

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

Установка, удаление и переустановка драйверов в Windows 10 довольно проста, и вот как это сделать:

Отключите принтер от ПК.
Запустите панель управления на своем компьютере.
Выберите параметр «Просмотр устройств и принтеров» в разделе «Оборудование и звук».
Найдите свой принтер в списке устройств.
Нажмите правой кнопкой мыши на свой принтер и выберите Удалить устройство.
Появится запрос, действительно ли вы хотите удалить выбранный принтер. Чтобы продолжить, выберите Да в приглашении.
Подключите принтер к компьютеру, и ваш компьютер должен автоматически установить драйверы.

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

5. Автоматизируйте службу диспетчера очереди печати

Стоит настроить службу диспетчера очереди печати в автоматическом режиме, чтобы посмотреть, решит ли это проблему «принтер в состоянии ошибки» на вашем ПК.

Нажмите клавиши Windows + R, чтобы открыть диалоговое окно «Выполнить», введите services.msc и нажмите Enter.
Найдите в списке службу диспетчера очереди печати, щелкните ее правой кнопкой мыши и выберите "Свойства".
Нажмите раскрывающееся меню рядом с типом запуска и выберите "Автоматически".
Нажмите «Применить», а затем «ОК» внизу.
Перезагрузите компьютер.

6. Обновите Windows 10

Само собой разумеется, что вы всегда должны обновлять свой ПК с Windows 10. Запуск более старой версии операционной системы может вызвать множество проблем, в том числе сообщение «принтер в состоянии ошибки».

Обновить Windows 10 легко, и вы можете сделать это следующим образом:

Нажмите клавишу Windows + I, чтобы открыть приложение "Настройки".
Нажмите «Обновление и безопасность» на экране «Настройки».
Выберите Центр обновления Windows на боковой панели слева.
Нажмите Проверить наличие обновлений справа.
Установите доступные обновления.

Устранение ошибки «Принтер в состоянии ошибки» в Windows 10

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

Если попытка подключения отклонена из-за сбоя проверки подлинности, связанного с неверным паролем или именем пользователя, клиенту возвращается сообщение, подобное следующему: «Ошибка входа для пользователя ' '. (Microsoft SQL Server, Ошибка: 18456)".

Дополнительная информация, возвращаемая клиенту, включает следующее:

"Ошибка входа в систему для пользователя ' '. (Провайдер данных .Net SqlClient)"

"Номер ошибки: 18456"

"Номер строки: 65536"

Также может быть возвращено следующее сообщение:

"Сообщение 18456, уровень 14, состояние 1, сервер, строка 1"

"Ошибка входа для пользователя ' '."

Дополнительная информация об ошибке

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

< td>11

Состояние	Описание
1	Информация об ошибке недоступна. Это состояние обычно означает, что у вас нет разрешения на получение сведений об ошибке. Для получения дополнительной информации обратитесь к администратору SQL Server.
2	Идентификатор пользователя недействителен.
5	Идентификатор пользователя недействителен.
6	Была предпринята попытка использовать имя входа Windows в SQL Server Аутентификация.
7	Вход в систему отключен, а пароль неверный.
8< /td>	Неверный пароль.
9	Неверный пароль.
Логин действителен, но доступ к серверу не выполнен. Одной из возможных причин этой ошибки является то, что пользователь Windows имеет доступ к SQL Server в качестве члена группы локальных администраторов, но Windows не предоставляет учетные данные администратора. Для подключения запустите программу подключения, выбрав параметр «Запуск от имени администратора», а затем добавьте пользователя Windows в SQL Server в качестве определенного имени входа.
12	Логин является действительным логином, но доступ к серверу не выполнен.
18	Необходимо изменить пароль.
38, 46	Не удалось найти базу данных, запрошенную пользователем.
58	Если SQL Server настроен на использование проверки подлинности Windows только, и клиент пытается войти в систему, используя аутентификацию SQL. Другой причиной является несовпадение SID.
102–111	Сбой AAD.
122 - 124	Сбой из-за пустого имени пользователя или пароля.
126	База данных, запрошенная пользователем, не существует.< /td>
132–133	Сбой AAD.

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

Дополнительная необычная возможная причина

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

Когда сервер настроен для проверки подлинности в смешанном режиме, а соединение ODBC использует протокол TCP, и в соединении явно не указано, что соединение должно использовать доверенное соединение.

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

Чтобы решить эту проблему, включите TRUSTED_CONNECTION = TRUE в строку подключения.

Примеры

В этом примере состояние ошибки аутентификации равно 8. Это указывает на неверный пароль.

Дата	Источник	Сообщение
2007-12-05 20:12:56.34	Вход в систему	Ошибка: 18456, серьезность: 14, состояние: 8.
2007-12-05 20:12:56.34	Вход в систему	Ошибка входа в систему для пользователя ' '. [КЛИЕНТ: ]

Когда SQL Server устанавливается с использованием режима проверки подлинности Windows, а затем изменяется на SQL Server и режим проверки подлинности Windows, вход sa изначально отключен. Это вызывает ошибку состояния 7: «Ошибка входа в систему для пользователя 'sa'». Чтобы включить логин sa, см. раздел Изменение режима аутентификации сервера.

Действие пользователя

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

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

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

Если ваша ошибка указывает на состояние 1, обратитесь к администратору SQL Server.

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

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

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

Мы попытались выполнить проверку таблиц DBCC, ограничений, отступов, каталогов и распределений, все прошло успешно и не сообщало об ошибках. Но DBBC CHECKDB терпит неудачу с вышеуказанной ошибкой. Мы пробовали с TABLOCK, но это не удалось, поскольку это стандартная версия, а SQL внутренне не может создать моментальный снимок. Опции No_infomsgs, errormsgs также не работают.

Версия SQL – стандартная версия 2012 года. Сообщите нам, есть ли решение этой проблемы.

Все ответы

Мы попытались выполнить проверку таблиц DBCC, ограничений, отступов, каталогов и распределений, все прошло успешно и не сообщало об ошибках. Но DBBC CHECKDB терпит неудачу с вышеуказанной ошибкой. Мы пробовали с TABLOCK, но это не удалось, поскольку это стандартная версия, а SQL внутренне не может создать моментальный снимок. Параметры No_infomsgs, errormsgs также не работают.

Версия SQL – стандартная версия 2012 года. Сообщите нам, есть ли решение этой проблемы.

Нет, DBCC CHECKDB создает внутренний моментальный снимок независимо от выпуска. Моментальный снимок БД вручную можно создать только в Enterprise, но тот, который создается внутри CHECKDB, делается во всех выпусках.

Возвращаясь к вашей ошибке, ошибка в теме, полный текст или что-то еще? Опубликуйте полное сообщение об ошибке.

Кроме того, проверьте следующее, чтобы исключить возможные проблемы:

<р>1. Ваша база данных находится в файловой системе, отличной от NTFS? DBCC CHECKDB не будет работать, если БД находится в системе, отличной от NTFS.

<р>2. Есть ли у вас свободное место на дисках, на которых находится ваша БД? потому что CHECKDB хранит снимок на том же диске

<р>3. запустите «Выбрать * из sys.databases» и посмотрите, есть ли уже созданный снимок для БД из предыдущего запуска DBCC? Не может быть двух снимков.

<р>4. Проверяются ли файловые группы только для чтения в вашей базе данных?

<р>5. Есть ли у служебной учетной записи SQL разрешения на создание разреженных файлов/снимков на диске, где находятся файлы БД?

<р>6. Проверьте журналы ошибок SQL и посмотрите, сможете ли вы что-то найти (сомневаюсь, что их будет много, потому что журнал ошибок записывается, если CHECKDB завершен успешно, но в вашем случае он завершается преждевременно)

<р>7. Проверьте журналы приложений просмотра событий Windows. (опять же, может быть немного по вышеуказанной причине)

<р>8. Какова общая память по сравнению с SQL? Заметили ли вы какие-либо ошибки, связанные с памятью, в этом поле?

Надеюсь, это поможет!

Не забудьте нажать "Отметить как ответ", если мой ответ ответил на ваш вопрос, или нажать "Проголосовать как полезный", если он вам чем-то помог.

В этой статье объясняется, как устранять ошибки, сообщаемые командой DBCC CHECKDB.

Исходная версия продукта: SQL Server
Исходный номер базы знаний: 2015748

Симптомы

При выполнении DBCC CHECKDB (или других подобных команд, таких как CHECKTABLE ) в журнал ошибок SQL Server записывается следующее сообщение:

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

Информация в сообщении, начинающемся с «внутреннего снимка базы данных», отображается только в том случае, если DBCC CHECKDB выполнялась в оперативном режиме, когда база данных не находится в режиме SINGLE_USER. Это связано с тем, что для интерактивной команды DBCC CHECKDB используется моментальный снимок внутренней базы данных, чтобы предоставить согласованный набор данных для проверки.

В этой статье не рассматривается устранение каждой конкретной ошибки, о которой сообщает DBCC CHECKDB, а рассматривается общий подход к обнаружению ошибок. Любая ссылка на CHECKDB в этой статье также относится к DBCC CHECKTABLE и CHECKFILEGROUP, если не указано иное.

Причина

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

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

Разрешение

Лучшее решение, если DBCC CHECKDB сообщает об ошибках согласованности, — это восстановление из известной резервной копии. Дополнительную информацию см. в разделе Восстановление и восстановление.

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

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

CHECKDB обнаружил 0 ошибок распределения и 15 ошибок согласованности в базе данных 'mydb'.
repair_allow_data_loss — это минимальный уровень исправления ошибок, обнаруженных командой DBCC CHECKDB (mydb).

Рекомендация по исправлению – это минимальный уровень исправления, позволяющий попытаться устранить все ошибки из CHECKDB . Это не означает, что этот вариант восстановления действительно исправит все ошибки. Кроме того, не все сообщения об ошибках могут потребовать устранения этого уровня ремонта. Это означает, что не все ошибки, о которых сообщает CHECKDB, когда рекомендуется repair_allow_data_loss, на самом деле приведут к потере данных. Необходимо выполнить восстановление, чтобы определить, приведет ли устранение ошибки к потере данных. Один из методов, помогающий определить, каким будет уровень исправления для каждой таблицы, — это использовать DBCC CHECKTABLE для любой таблицы, сообщающей об ошибке. Это покажет минимальный уровень ремонта для данной таблицы.

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

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

Исследуйте основную причину ошибок согласованности базы данных

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

Подробнее

Подробнее о синтаксисе DBCC CHECKDB и сведениях/параметрах о том, как выполнить команду, см. в разделе DBCC CHECKDB (Transact-SQL).

Если с помощью CHECKDB были обнаружены какие-либо ошибки, в журнале ERRORLOG для целей отчета об ошибках появляются дополнительные сообщения, подобные приведенным ниже:

Дата/время spid53 Использование 'dbghelp.dll' версии '4.0.5'
Дата/время spid53 **Дамп потока - spid = 0, EC = 0x00000000855F5EB0
Дата/время spid53 ***Дамп стека отправляется вFilePath\FileName
Дата/время spid53 * ********************************** ****************************************************
Дата/время spid53 *
Дата/время spid53 * BEGIN STACK DUMP:
Дата/время spid53 * Дата/время spid 53
Дата/время spid53 *
Дата/время spid53 * Повреждение базы данных DBCC
Дата/времяspid53 *
Дата/время spid53 * Входной буфер 84 байта -
Дата/время spid53 * dbcc checkdb(mydb)
Дата/время spid53 *
Дата/время spid53 * ************************************************* *************************************
Дата/время spid53 * ----- -------------------------------------------------- ------------------------
Дата/время spid53 * Короткий дамп стека
Дата/время spid53 Подпись стека для дампа 0x00000000000001E8
Дата/время spid53 Внешний du код возврата процесса mp 0x20002001.

Информация об ошибке отправлена в систему отчетов об ошибках Watson.

Файлы, используемые для отчетов об ошибках, включают файл SQLDump .txt. Этот файл может быть полезен для исторических целей, поскольку он содержит список ошибок, обнаруженных с помощью CHECKDB, в формате XML.

Чтобы узнать, когда в последний раз выполнялась команда DBCC CHECKDB без ошибок для базы данных (последняя известная чистая проверка CHECKDB ), проверьте в SQL Server ERRORLOG сообщение, подобное приведенному ниже, для вашей базы данных или системной базы данных (это сообщение записывается как сообщение информационного уровня в журнале событий приложений Windows с EventID = 17573):

Дата/время CHECKDB spid7s для базы данных "master" завершена без ошибок onDate/Time22:11:11.417 (по местному времени). Это только информационное сообщение; никаких действий пользователя не требуется

Читайте также: