Ошибка в эксель module not found

Обновлено: 05.07.2024

Конфигурация компьютера
Процессор: AMD Ryzen 5 1600
Материнская плата: GIGABYTE B450M DS3H
Память: Kingston ValueRAM [KVR24N17S8/8] 8 ГБ
HDD: KINGSTON SV300S37A120G ATA 120ГБт SSD; SAMSUNG HD501LJ, SATA, 500ГБт; ST2000VM003-1CT164 ATA Device 2ТБт
Видеокарта: GIGABYTE Radeon R7 250 1100Mhz PCI-E 3.0 2048Mb 1800Mhz 128 bit DVI HDMI HDCP
Звук: Realtek ALC887
Блок питания: CoolerMaster MasterWatt Lite 600W, 2019
Монитор: Samsung SyncMaster 2443, 24''
ОС: Windows 10 Pro 64Bit

Понятно, что ей библиотек не хватает. Но как узнать, чего именно? »

dislike, у вас есть доступ к VBA-проекту в редакторе по alt+F11?
Зайдите в Tools-References, проверьте наличие пунктов с надписью MISSING, если присутствуют - уберите галочки.
Если проблема сохранится - запустите код, получите ошибку, после чего в VBA редакторе посмотрите какая строчка выделена. Озвучьте, либо посмотрите в поиске, какую библиотеку нужно подключить.

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

dislike, коль Вы не приложили архив с документом, надо полагать он особо секретный?

Alt-F11, ищете обработчик «любой кнопки», устанавливаете точку останова, нажимаете кнопку и начинаете отлаживать. Для начала можете действительно проверить наличие всех необходимых библиотек (\Tools\References). Разумеется, если проект не закрыт от просмотра.

Update: Коллега a_axe оказался быстрее .

у вас есть доступ к VBA-проекту в редакторе по alt+F11? »

Это я уже пробовал, эта менюшка неактивна совсем (

коль Вы не приложили архив с документом, надо полагать он особо секретный? »

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

Alt-F11, ищете обработчик «любой кнопки», устанавливаете точку останова, нажимаете кнопку и начинаете отлаживать.

Спасибо, но можно поподробнее, как для идиота? Я такими вещами ещё не занимался, буду долго тыкаться как слепой котенок, и увы, времени детально разбираться совершенно нет, работой завалили всей и сразу

Make sure you're not in Break Mode. Try clicking Run->Reset.

Конфигурация компьютера
Процессор: AMD Ryzen 5 1600
Материнская плата: GIGABYTE B450M DS3H
Память: Kingston ValueRAM [KVR24N17S8/8] 8 ГБ
HDD: KINGSTON SV300S37A120G ATA 120ГБт SSD; SAMSUNG HD501LJ, SATA, 500ГБт; ST2000VM003-1CT164 ATA Device 2ТБт
Видеокарта: GIGABYTE Radeon R7 250 1100Mhz PCI-E 3.0 2048Mb 1800Mhz 128 bit DVI HDMI HDCP
Звук: Realtek ALC887
Блок питания: CoolerMaster MasterWatt Lite 600W, 2019
Монитор: Samsung SyncMaster 2443, 24''
ОС: Windows 10 Pro 64Bit

Цитата a_axe:
у вас есть доступ к VBA-проекту в редакторе по alt+F11? »
Есть »

dislike, имеется ввиду, что вы можете увидеть и отредактировать любую часть текста кода VBA?
Т.е. в VBA редакторе в project explorer (окошко в левой части экрана с отображением проекта вида VBAProject(Имя_файла) ), по нажатию на плюсик у вас открывается содержимое, и вы видите код любого листа/модуля (а не просто ограничились фактом открытием редактора)?

Если нажатие на плюсик дает ошибку, то возможны варианты:

PS. ну понятное дело - указанный Break Mode нужно проверить в первую очередь.

Make sure you're not in Break Mode. Try clicking Run->Reset. »

Ага, сделал, там ошибка
Missing: OnBttnAddInForWord 1.0 Type Library
и ссылается это все в директорию офиса / Office14 / onbttnwd.dll

Файла такого естественно нет

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

Не так давно очередной раз столкнулся с ошибками приложения Excel при попытке включения макросов после открытия файлов .xlsm. Вспомнил, что подобные проблемы преследуют пользователей довольно давно, но чаще всего они наблюдались с Excel 2013 и Excel 2016. Характерные особенности этой группы ошибок следующие:

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

Ну и по горячим следам очередного инцидента, дабы не откладывать на потом, решил для себя собрать небольшой хаб по ошибкам приложения Excel с последующей модификацией, дабы опять не терять время на поиск информации в Сети и на составление облака причин.
Суть в том, что в процессе открытия файла xlsm, и при отключенных макросах, в верхней части основного окна (над таблицей), высвечивается строка уведомления: ПРЕДУПРЕЖДЕНИЕ СИСТЕМЫ БЕЗОПАСНОСТИ Запуск макросов отключен , с кнопкой включения содержимого (макросов). Как только пользователь её нажимает, Excel попросту аварийно завершается (падает) с ошибкой Программа Microsoft Excel не работает и характерным окном уведомления:

При этом было замечено, что непосредственно перед возникновением ошибки приложения Excel никаких системных обновлений и обновлений пакета Office не устанавливалось. Возможно, каким-то образом задействованы последние обновления на Office, но прямой связи я не заметил, а подробного исследования проблемы не проводил. При этом зависимости от версии операционной системы (мною лично сбои наблюдались на Windows 10 LTSC и Windows 7 Professional) так же выявлено не было. При анализе аварийного дампа приложения ( *.hdmp ) обычно можно увидеть подобную информацию исключения (вывод урезан):

ExceptionAddress : 00007ff86a1e05ac ( VBE 7+ 0x00000000001405ac ) ERROR_CODE : ( NTSTATUS ) 0xc0000005 - < Unable to get error code text > EXCEPTION_CODE : ( NTSTATUS ) 0xc0000005 - < Unable to get error code text >

обычно это NTSTATUS с кодом c0000005 - Access violation, доступ запрещен. И чаще всего в дампе можно увидеть такой вот стек потока (вывод оптимизирован для улучшения представления):

000000b9 ` 1acfdd00 000001d3 ` 2fb24e90 : 000001d3 ` 5a0e0ef0 00000000 ` 00000000 : VBE 7+ 0x1405ac 000000b9 ` 1acfdd08 000001d3 ` 24c1fe20 : 00000000 ` 00000000 000001d3 ` 2fda9640 : 0x000001d3 ` 2fb24e90 000000b9 ` 1acfdd10 000001d3 ` 6cf35760 : 000001d3 ` 2fda9640 000001d3 ` 045c9b30 : 0x000001d3 ` 24c1fe20 000000b9 ` 1acfdd18 000001d3 ` 5a0e0ef0 : 000001d3 ` 045c9b30 000001d3 ` 2fcbb2b0 : 0x000001d3 ` 6cf35760 000000b9 ` 1acfdd20 00000000 ` 00000000 : 000001d3 ` 2fcbb2b0 000001d3 ` 2fcbb318 : 0x000001d3 ` 5a0e0ef0

из которого единственное что понятно, так это то, что падение Excel происходит в недрах функций библиотеки vbe7.dll (среда исполнения VBA), подгруженной в адресное пространство процесса. Это указывает на проблемы с обработчиком VBA-скриптов, в контексте Excel чаще именуемых макросами.

НЕРЕШЕННОЕ: при отладке приложений из комплекта MS Office, вы не увидите имен функций в стеке вызовов, поскольку отсутствуют отладочные символы как к основным исполняемым файлам (Excel/Word/Outlook), так и к многочисленным библиотекам. Интересно, есть ли какое-либо решение?

Так что же такое VBA и для чего он предназначается?

VBA (Visual Basic for Application) - язык макропрограммирования, основанный на языке Visual Basic.

В приложениях, входящих в комплект MS Office, таких как Excel, Word, PowerPoint и Access, VBA используется для автоматизации множества рутинных задач (напр.: повторяющихся однотипных действий), позволяет создавать формы для общения с пользователем и предлагает множество иного богатого функционала. При помощи VBA доступно управление электронной таблицей посредством объектно-ориентированной модели кода/данных, при помощи VBA-кода входные данные таблиц могут быть обработаны и представлены в итоговых (результирующих) таблицах и диаграммах (графиках). Таблица становится интерфейсом кода, позволяя легко работать, изменять его и управлять расчётами. На выходе VBA проект, используемый в структурах описанных выше приложений (электронные таблицы Excel, презентации PowerPoint, базы Access), компилируется в специальный бинарный исполняемый файл, который размещается внутри файла основного формата. Применительно к Excel это файл vbaProject.bin , который располагается внутри *.xslm-файла в директории /xl , представляющий собой бинарный исполняемый файл проекта, содержащий макрос в откомпилированном (готовом к исполнению) виде.

Наиболее вероятной причиной сбоя является повреждение блока кода VBA, содержащегося в книге Excel. Об истоках этого остается только догадываться, возможно что в структуре .xlsm-файла, в процессе работы с документом, происходят какие-то [непредвиденные разработчиками] изменения, способные приводить блок кода в неработоспособное состояние.

Решение 1: вставка нового листа

Выполните приведенную последовательность действий:

Открываем [проблемный] .xlsm-файл (файл с макросами).
Не нажимаем кнопку Включить содержимое .
Добавляем в книгу Excel новый лист: правая кнопка мыши на ярлыках Лист1/Лист2/Лист3 → Вставить → Лист .
Сохраняем электронную таблицу. Закрываем Excel.
Открываем проблемный файл заново и включаем макросы.

Решение 2: перекомпиляция проекта

Выполните последовательность действий:

Запускаем и открываем новую книгу Excel (не ваш проблемный файл).
Открываем меню Файл - выбираем Параметры - далее открываем Центр управления безопасностью и заходим в Параметры центра управления безопасностью .
В разделе Параметры макросов - выставляем чекбокс Отключить все макросы с уведомлением .
В разделе Надежные расположения - выставляем чекбокс Отключить все надежные расположения .
В разделе Надежные документы - выставляем чекбокс Отключить надежные документы .
Жмем везде OK . Закрываем Excel.
Открываем [проблемный] .xlsm-файл (файл с макросами).
Не нажимаем кнопку Включить содержимое .
Открывает редактор Visual Basic при помощи комбинации клавиш Alt + F11 . Либо можно использовать обходной маневр: в настройках включаем меню Разработчик , после этого в появившемся сверху в ленте меню Разработчик выбираем пункт Visual Basic .
В открывшемся окне редактора Visual Basic (VBA редактор) пересохраняем проект: для этого жмем на панели инструментов кнопку Сохранить (изображение дискетки или комбинация Ctrl + S ).
Выбираем из меню Debug - выбираем пункт меню Compile VBA Project :

Решение 3: добавление модуля

Дополнительное решение состоит в том, что бы внести изменения в макрос без перекомпиляции.

Открываем [проблемный] .xlsm-файл (файл с макросами).
Не нажимаем кнопку Включить содержимое .
Открывает редактор Visual Basic (при помощи комбинации клавиш Alt + F11 ).
Открываем меню Tools → пункт Options . В открывшемся окне переходим на вкладку General и деактивируем чекбокс Compile on Demand :

Дополнительные ошибки Excel и предложенные решения

Ошибки, предупреждения, причина и предложенные решения

Выбранный компилятор не поддерживает COM-объекты создания.

Повторно выполните mbuild -setup -client mbuild_com и выберите поддерживаемый компилятор.

Обычно вызываемый mwcomutil.dll не быть указанным.

Откройте окно DOS, папки изменения к matlabroot \bin\win64 ( matlabroot представляет местоположение MATLAB в вашей системе), и запустите команду
mwregsvr mwcomutil.dll .

DLL проекта не указан.

Несовместимый DLL MATLAB существует где-нибудь на системном пути.

Если DLL не указан, откройте окно DOS, папки изменения к <projectdir>\distrib ( <projectdir> представляет местоположение ваших файлов проекта), и запустите команду:
mwregsvr <projectdll>.dll .

Каждый раз, когда вы имеете несколько версий MATLAB, гарантируете, что новейшая версия MATLAB появляется на вашем пути сначала. Можно проверить, что новейшая версия MATLAB находится на пути сначала путем ввода path в командной строке DOS. См. таблицу Required Locations to Develop и Use Components.

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

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

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

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

Добавьте следующий DLLs в свой путь к Windows:

Различные версии MATLAB Runtime и MATLAB приводят к ошибке IMWDispatchDriver.

Проверяйте на текущие версии MATLAB и MATLAB Runtime . Проверьте версию MATLAB путем ввода пути MATLAB в командной строке DOS. Если версии не совпадают с обновлением и устанавливают новую версию MATLAB Runtime , который совпадает с текущей версией MATLAB.

Несколько версий MATLAB, работающего на системе, приводят к этой ошибке.

Укажите файлы реестра mwcomutil.dll и mwcommgr.dll. Откройте окно DOS, CD к matlabroot \bin\win64 ( matlabroot представляет местоположение MATLAB в вашей системе), и запустите команду
mwregsvr mwcomutil.dll
mwregsvr mwcommgr.dll

Установите Инструменты Visual Studio при установке Visual Studio, чтобы получить доступ ко всем файлам и пакету развертываемый архив с целью Excel Integration.

Необходимые местоположения, чтобы разработать и использовать компоненты

И целевая машина компонента

Компонент	Машина разработки	Целевая машина
MATLAB Runtime	Убедитесь тот matlabroot \bin\win64 появляется на вашем системном пути перед любыми другими установками MATLAB. matlabroot ваша корневая папка MATLAB.)	Проверьте тот <MATLAB_RUNTIME_INSTALL_DIR> \ <ver> \runtime\ <arch> появляется на вашем системном пути. Для получения дополнительной информации смотрите Установленный Путь MATLAB Runtime для Развертывания Во время выполнения

Ошибки Microsoft Excel и предложенные решения

Ошибка, причина и решения

Безопасность макросов для Excel установлена в High .

Установите безопасность макросов Excel на Medium на вкладке Security Level путем выполнения следующего:

Для Microsoft Office 2003 :

Щелкнуть
Tools> Macro> Security.

Для Security Level выберите Medium.

Для Microsoft Office 2007 :

Нажмите 2 007 кнопок Office на ленте Microsoft Office ( ).

Нажмите Excel Options > Trust Center > Trust Center Settings > Macro Settings.

В Developer Macro Settings выберите Trust access to the VBA project object model.

Для Microsoft Office 2010 :

Нажмите File > Options > Trust Center > Trust Center Settings > Macro Settings.

В Developer Macro Settings выберите Trust access to the VBA project object model.

Функциональные проблемы мастера

Проблемы, причина и предложенные решения

Функциональная Справка Мастера не появляется.

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

Функциональный Мастер неправильно функционировал с неустановленной ошибкой

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

Если вы используете Microsoft Office 2007 или 2010 , нажмите Developer > Macros.

Если вы используете Microsoft Office 2003 , нажмите Tools > Macros > Macro.

Совет

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

Если вы используете Office 365:

Нажмите File.

Нажмите Options и выберите Customize Ribbon.

Под Customize the Ribbon: выберите Main Tabs и проверяйте флажок Developer.

Если вы используете Microsoft Office 2007 или 2010 :

Нажмите Excel Options.

В области Top Options for Working With Excel выберите Show Developer tab in the Ribbon.

Вы получаете ошибку при попытке создать макрос с Функциональным Мастером

Я уже довольно давно работаю с VBA, но все еще не уверен в обработке ошибок.

Однако мне все еще интересно, был ли способ, которым я раньше выполнял ErrorHandling, был полностью неправильным: Блок 1

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

Если я правильно понял, должно быть так:

Блок 2

Или даже так: Блок 3

Чаще всего я вижу, что ошибка «Catcher» находится в конце подпрограммы, а подпрограмма на самом деле заканчивается раньше «Exit Sub», но, однако, это не сбивает с толку, если подпрограмма довольно большой, если прыгнуть наоборот, чтобы прочитать код?

Блок 4

Должно быть как в блоке 3?

Я бы точно не стал использовать Block1. Кажется неправильным иметь блок Error в операторе IF, не связанный с Errors.

Блоки 2, 3 и 4, я думаю, являются вариациями темы. Я предпочитаю использовать блоки 3 и 4 вместо 2 только из-за неприязни к оператору GOTO; Я обычно использую метод Block4. Это один из примеров кода, который я использую, чтобы проверить, добавлена ли библиотека Microsoft ActiveX Data Objects 2.8, и если нет, добавить или использовать более раннюю версию, если 2.8 недоступна.

Я надеюсь, что это подведет итог для других. Есть объект Err и активный (или неактивный) ErrorHandler . И то, и другое необходимо обработать и сбросить для новых ошибок.

Вставьте это в рабочую книгу и просмотрите ее с помощью F8.

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

Блок 3 терпит неудачу, потому что нет оператора Resume , поэтому любая попытка обработки ошибок после этого потерпит неудачу.

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

Ключом к выполнению этой работы является использование оператора Resume , сразу за которым следует другой оператор On Error . Resume находится внутри обработчика ошибок и перенаправляет код на метку EndTry1 . Вы должны немедленно установить другой оператор On Error , чтобы избежать проблем, поскольку предыдущий обработчик ошибок "возобновит работу". То есть он будет активен и готов обработать очередную ошибку. Это может привести к повторению ошибки и переходу в бесконечный цикл.

Чтобы избежать повторного использования предыдущего обработчика ошибок, вам нужно установить On Error на новый обработчик ошибок или просто использовать On Error Goto 0 для отмены всей обработки ошибок.

Я все просто:
На уровне модуля я определяю две переменные и устанавливаю одну для имени самого модуля.

Внутри каждой подпрограммы / функции модуля я определяю локальную переменную

Я установил ThisRoutineName на имя подпрограммы или функции

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

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

Затем у меня есть отдельный модуль, который я вставляю во все проекты, под названием «mod_Error_Handler».

Две основные цели обработки ошибок:

Итак, как бы вы это сделали?

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

Это может выглядеть примерно так (к сведению: моя называется frmErrors):

Обратите внимание на следующие метки:

lblHeadline
lblSource
lblProblem
lblResponse

Также стандартные командные кнопки:

Игнорировать
Повторить
Отмена

В коде этой формы нет ничего примечательного:

По сути, вы хотите знать, какую кнопку нажимал пользователь при закрытии формы.

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

У вас могут быть ошибки, которые будут настраиваться только для вашего приложения. Обычно это краткий список ошибок, относящихся только к вашему приложению. Если у вас еще нет модуля констант, создайте тот, который будет содержать ENUM ваших пользовательских ошибок. (ПРИМЕЧАНИЕ: Office '97 НЕ поддерживает ENUMS.). ENUM должен выглядеть примерно так:

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

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

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

У вас есть поистине замечательный ответ от ray023, но ваш комментарий о том, что это, вероятно, перебор, уместен. Для «облегченной» версии .

Блок 1 - это, ИМХО, плохая практика. Как уже указывалось osknows, смешивать обработку ошибок с кодом нормального пути - это не хорошо. Во-первых, если возникает новая ошибка во время действия условия ошибки, у вас не будет возможности обработать ее (если только вы не вызываете из подпрограммы, которая также есть обработчик ошибок, где выполнение будет «всплывать»).

Блок 2 выглядит как имитация блока Try / Catch. Это должно быть хорошо, но это не Путь VBA. Блок 3 - это вариант блока 2.

Блок 4 - это упрощенная версия VBA Way. Я бы настоятельно посоветовал использовать его или что-то в этом роде, потому что это то, что ожидает любой другой программист VBA, унаследовавший код. Однако позвольте мне представить небольшое расширение:

Что касается вашего возражения против этого формата "прыгать вокруг", A) это то, что программисты VBA ожидают, как было сказано ранее, & B) ваши подпрограммы должны быть достаточно короткими, чтобы их не было далеко.

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