Visual Studio 2012 — ошибка выполнения приложения C ++, развернутого с помощью InstallShield (windows)
У меня есть простая программа на C ++ (командная строка с библиотеками Boost), которую я разработал в Visual Studio Community 2013. Я хочу развернуть ее на других компьютерах Windows, поэтому я тестирую InstallShield LE в Visual для этого (я новичок в InstallShield) , Я добавил проект InstallShield в текущее решение, и мне удалось создать setup.exe,
Когда я тестирую его на другом компьютере, настройка кажется нормальной, но когда я пытаюсь запустить приложение, у меня появляется странная ошибка:
MyProgramm.exe --help
Посылает правильный результат (но это не очень интересно).
MyProgramm.exe -i InputDirectory -o OutputDirectory
Сбой с Windows, отображающей это сообщение:
Из-за проблемы программа перестала работать правильно. Windows закроет программу и уведомит вас, если решение доступно.
Что я упустил?
Я построил только конфигурацию выпуска. Как я могу быть уверен, что проверил все модули слияния или предварительные условия InstallShield?
Решение
Вы должны будете определить, что происходит не так. Обычно описываемый вами признак указывает, что исключение вызвало завершение процесса. Одним из распространенных источников таких исключений является неправильное использование неверного указателя.
Но почему он работает на одном компьютере, а не на другом? В зависимости от кода это могут быть случайные случайные вещи. Но пока это повторяется каждый раз, это, скорее всего, будет экологическим. Это может означать отсутствующий файл данных, отсутствующий раздел реестра, отсутствующий сервис или отсутствующую зависимость .dll.
Поскольку вы можете запустить программу хотя бы одним способом, вы знаете, что это не статическая зависимость. Если бы это было так, вы бы получили сообщение о невозможности загрузить какой-либо файл или одну из его зависимостей. Но вместо этого в некоторых путях выполнения вы видите сбой. Так что, если это зависимость, это то, что InstallShield называет динамической зависимостью. Я лично не большой поклонник этого (я бы предпочел, чтобы мне точно сказали, что может потребоваться), но есть мастер динамического сканирования зависимостей, который может помочь идентифицировать такие файлы и включить их в проект.
Это поможет, только если проблема связана с чем-то вроде этого:
HMODULE hMod = ::LoadLibrary(TEXT("SomeFunky.dll"));
SOMEPROC proc = (SOMEPROC)::GetProcAddress(hMod, "SomeFunkyProc");
int result = proc(some, args);
Или, может быть, из COM-варианта, который выглядит примерно так:
CComPtr<ISomeFace> spSomeFace;
HRESULT hr = spSomeFace.CoCreateInstance(CLSID_SomeFace);
hr = spSomeFace->SomeMethod(some, args);
Общая проблема здесь в том, что ни один из этих блоков кода не проверяет функцию, которую он вызывает, безопасно вызывать. В первом случае proc (или даже hMod) может быть нулевым; во-вторых, spSomeFace возможно, не был успешно создан экземпляр. Хотя код может (и должен) предотвращать сбой этих сценариев, исправление сбоя не заставит ваше приложение действительно делать то, что оно должно, и вам все равно придется устранить причину, по которой процедура, dll или экземпляр не смогли быть инициализирован по желанию.
Также возможно, что вам не хватает файла данных или раздела реестра, который в какой-то момент используется некорректно. Например, код может предполагать, что файл данных существует, создавать указатель из данных, которые он читает, и не может работать правильно, потому что файл не был доступен, и, таким образом, буфер, который он считывал, фактически никогда не инициализировался.
Короче говоря, чтобы решить эту проблему, если это не сценарий зависимости, с которым может помочь сканер динамических зависимостей, вам, возможно, придется отлаживать рассматриваемый код. Вы можете попробовать такие инструменты, как Process Monitor, и искать ошибки, связанные с вашим приложением незадолго до сбоя. Если у вас есть источник и символы, вы можете попробовать запустить программу под WinDbg, чтобы точно определить, что происходит сбой, а затем попытаться выяснить, почему это происходит в одной среде, а не в другой. Но из той информации, которую вы уже предоставили, никто не может сказать вам ответ.
Другие решения