Как исправить ошибку ShellExecuteEx failed

При попытке установить программу на вашем компьютере с Windows, Если вы видите “ShellExecuteEx failed” в сопровождении различных кодов, то этот пост поможет вам.

Сопутствующие коды ошибок могут быть: 2, 5, 67, 255, 1155, 1460, 8235, 2147221003, и т. д. Эта ошибка обычно возникает, если установщик требует прав администратора, файл установки был поврежден или существует конфликт приложений.

ShellExecuteEx — это функция ОС, которая выполняет операцию над указанным файлом. Если операция завершится неудачно, вы получите эту ошибку.

ShellExecuteEx сбой как исправить

Давайте подробно рассмотрим эти методы.

Попробуйте запустить приложение от имени администратора

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

Запуск с правами администратора

Загрузите установщик еще раз, а затем установите повторно

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

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

Здесь вы можете приобрести ключ лицензии Windows 10 Pro 2020. Вы сразу же получаете ваш собственный уникальный ключ активации. После ввода лицензионного ключа вы начинаете использовать лицензионную операционную систему без ограничений, а также получать последующие пакеты обновлений, выпускаемые Microsoft.

Запустите сканирование SFC

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

SFC scan не только находит проблемный системный файл, но и исправляет его.

Windows PowerShell c правами администратора

Выполните команду: sfc /scannow
Подождите несколько секунд, так как требуется время для завершения сканирования.
Если проблема в этом, то ошибка должна быть решена.

сканирование SFC. jpg

Но если есть действительно большая проблема, то вы можете столкнуться с сообщением, говорящим: «Windows Resource Protection нашел поврежденные файлы, но не смог исправить».

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

Сброс системных звуков по умолчанию

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

Откройте диалоговое окно Выполнить, нажав клавишу Win + R.

И введите mmsys. cpl нажмите Enter.

Нажмите на вкладку Звуки. Выберите «По умолчанию» в звуковой схеме.

Нажмите на кнопку Применить, а затем на кнопку ОК.

Сброс системных звуков Windows 10

Мой первый опыт восстановления базы данных Postgres после сбоя (invalid page in block 4123007 of relatton base/16490)

Хочу поделиться с вами моим первым успешным опытом восстановления полной работоспособности базы данных Postgres. С СУБД Postgres я познакомился пол года назад, до этого опыта администрирования баз данных у меня не было совсем.

Я работаю полу-DevOps инженером в крупной IT-компании. Наша компания занимается разработкой программного обеспечения для высоконагруженных сервисов, я же отвечаю за работоспособность, сопровождение и деплой. Передо мной поставили стандартную задачу: обновить приложение на одном сервере. Приложение написано на Django, во время обновления выполняются миграции (изменение структуры базы данных), и перед этим процессом мы снимаем полный дамп базы данных через стандартную программу pg_dump на всякий случай.

Во время снятия дампа возникла непредвиденная ошибка (версия Postgres – 9.5):

Ошибка «invalid page in block» говорит о проблемах на уровне файловой системы, что очень нехорошо. На различных форумах предлагали сделать FULL VACUUM с опцией zero_damaged_pages для решения данной проблемы. Что же, попрробеум…

Подготовка к восстановлению

ВНИМАНИЕ! Обязательно сделайте резервную копию Postgres перед любой попыткой восстановить базу данных. Если у вас виртуальная машина, остановите базу данных и сделайте снепшот. Если нет возможности сделать снепшот, остановите базу и скопируйте содержимое каталога Postgres (включая wal-файлы) в надёжное место. Главное в нашем деле – не сделать хуже. Прочтите это.

Сервер был физическим, снять снепшот было невозможно. Бекап снят, двигаемся дальше.

Проверка файловой системы

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

В моём случае файловая система с базой данных была примонтирована в «/srv» и тип был ext4.

Останавливаем базу данных: systemctl stop postgresql@9.5-main. service и проверяем, что файловая система никем не используется и её можно отмонтировать с помощью команды lsof:
lsof +D /srv

Мне пришлось ещё остановить базу данных redis, так как она тоже исползовала «/srv». Далее я отмонтировал /srv (umount).

Далее с помощью утилиты dumpe2fs (sudo dumpe2fs /dev/mapper/gu2—sys-srv | grep checked) можно убедиться, что проверка действительно была произведена:

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

Попытка 1: zero_damaged_pages

Подключаемся к базе через psql аккаунтом, обладающим правами суперпользователя. Нам нужен именно суперпользователь, т. к. опцию zero_damaged_pages может менять только он. В моём случае это postgres:

Опция zero_damaged_pages нужна для того, чтобы проигнорировать ошибки чтения (с сайта postgrespro):

Включаем опцию и пробуем делать full vacuum таблицы:

К сожалению, неудача.

Мы столкнулись с аналогичной ошибкой:

pg_toast – механизм хранения «длинных данных» в Postgres, если они не помещаются в одну страницу (по умолчанию 8кб).

Попытка 2: reindex

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

reindex завершился без проблем.

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

Попытка 3: SELECT, LIMIT, OFFSET

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

В моём случае таблица содержала 1 628 991 строк! По-хорошему необходимо было позаботиться о партициирвоании данных, но это тема для отдельного обсуждения. Была суббота, я запустил вот эту команду в tmux и пошёл спать:

К утру я решил проверить, как обстоят дела. К моему удивлению, я обнаружил, что за 20 часов было просканировано только 2% данных! Ждать 50 дней я не хотел. Очередной полный провал.

Но я не стал сдаваться. Мне стало интересно, почему же сканирование шло так долго. Из документации (опять на postgrespro) я узнал:

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

Применяя LIMIT, важно использовать также предложение ORDER BY, чтобы строки результата выдавались в определённом порядке. Иначе будут возвращаться непредсказуемые подмножества строк.

Очевидно, что вышенаписанная команда была ошибочной: во-первых, не было order by, результат мог получиться ошибочным. Во-вторых, Postgres сначала должен был просканировать и пропустить OFFSET-строк, и с возрастанием OFFSET производительность снижалась бы ещё сильнее.

Попытка 4: снять дамп в текстовом виде

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

Но для начала, ознакомимся со структурой таблицы ws_log_smevlog:

В нашем случае у нас есть столбец «id», который содержал уникальный идентификатор (счётчик) строки. План был такой:

Снятия дампа, как и ожидалось, прервался с той же самой ошибкой:

Попытка 5: SELECT, FROM, WHERE > Неудачи делают нас сильнее. Не стоит никогда сдаваться, нужно идти до конца и верить в себя и свои возможности. Поэтому я решил попробовать ешё один вариант: просто просмотреть все записи в базе данных по одному. Зная структуру моей таблицы (см. выше), у нас есть поле id, которое является уникальным (первичным ключом). В таблице у нас 1 628 991 строк и id идут по порядку, а это значит, что мы можем просто перербрать их по одному:

Если кто не понимает, команда работает следующим образом: просматривает построчно таблицу и отправляет stdout в /dev/null, но если команда SELECT проваливается, то выводится текст ошибки (stderr отправляется в консоль) и выводится строка, содержащая ошибку (благодаря ||, которая означает, что у select возникли проблемы (код возврата команды не 0)).

Мне повезло, у меня были созданы индексы по полю id:

А это значит, что нахождение строки с нужным id не должен занимать много времени. В теории должно сработать. Что же, запускаем команду в tmux и идём спать.

К утру я обнаружил, что просмотрено около 90 000 записей, что составляет чуть более 5%. Отличный результат, если сравнивать с предыдущим способом (2%)! Но ждать 20 дней не хотелось…

Попытка 6: SELECT, FROM, WHERE id >= and id <

У заказчика под БД был выделен отличный сервер: двухпроцессорный Intel Xeon E5-2697 v2, в нашем расположении было целых 48 потоков! Нагрузка на сервере была средняя, мы без особых проблем могли забрать около 20-ти потоков. Оперативной памяти тоже было достаточно: аж 384 гигабайт!

Поэтому команду нужно было распараллелить:

Тут можно было написать красивый и элегантный скрипт, но я выбрал наиболее быстрый способ распараллеливания: разбить диапазон 0-1628991 вручную на интервалы по 100 000 записей и запустить отдельно 16 команд вида:

Но это не всё. По идее, подключение к базе данных тоже отнимает какое-то время и системные ресурсы. Подключать 1 628 991 было не очень разумно, согласитесь. Поэтому давайте при одном подключении извлекать 1000 строк вместо одной. В итоге команда преобразилоась в это:

Открываем 16 окон в сессии tmux и запускаем команды:

Через день я получил первые результаты! А именно (значения XXX и ZZZ уже не сохранились):

Это значит, что у нас три строки содержат ошибку. id первой и второй проблемной записи находились между 829 000 и 830 000, id третьей – между 146 000 и 147 000. Далее нам предстояло просто найти точное значение id проблемных записей. Для этого просматриваем наш диапазон с проблемными записями с шагом 1 и идентифицируем id:

Счастливый финал

Мы нашли проблемные строки. Заходим в базу через psql и пробуем их удалить:

К моему удивлению, записи удалились без каких-либо проблем даже без опции zero_damaged_pages.

Затем я подключился к базе, сделал VACUUM FULL (думаю делать было необязательно), и, наконец, успешно снял бекап с помощью pg_dump. Дамп снялся без каких либо ошибок! Проблему удалось решить таким вот тупейшим способом. Радости не было предела, после стольких неудач удалось найти решение!

Благодарности и заключение

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

Ну и напоследок, хотел бы сказать спасибо компании PostgresPro за переведённую документацию на русский язык и за полностью бесплатные online-курсы, которые очень сильно помогли во время анализа проблемы.

При подключении оборудования произошла ошибка 999 в Атол

В конце рабочего дня кассиры вынуждены закрывать отчёты на своих рабочих местах. Но по непонятным причинам возникает сбой, и появляется сообщение «При подключении оборудования произошла ошибка» (999) в Атол. Что это значит и как решить эту проблему — читайте в этой статье далее.

Ошибка 999 в Атол – каковы причины?

Тестирование 1С платформы при подключении оборудования

Для этого перейдите в настройки РМК:

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

Проверка драйвера

Выполните следующие действия:

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

Рассмотрим способ настройки драйвера Атол, когда появляется сбой 999. Для этого нужно нажать на кнопку « Пуск » в Windows.

После этого открываем 1С предприятие и открываем смену. Если такой способ не помог решить ошибку при подключении оборудования 999 в Атол, попробуйте следующую инструкцию.

Изменение протокола и канала устройства Атол

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

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