Проблеми з Windows 7, 64 біт, DLL

У мене проблема з нашим виконуваним файлом. Я запускаю цей 32-розрядний виконуваний файл C ++ на 64-розрядному вікні розробки Windows 7, в якому також є всі ті програми Microsoft (Visual Studio 2008 + 2010, TFS, SDK, Microsoft Office) ... І він все ще працює просто чудово.

Тепер я отримав клієнтську інсталяцію тієї самої програми, і мені запропонували протестувати її на чистій установці Windows 7. Таким чином, я отримав один 64-розрядний VMware для Windows 7 і оновив його до Windows 7 SP 1 (та сама версія, яку налаштовує моя скринька розробника). Але в моєму вікні розробника все нормально, програма не працює з вікном VMware (30 днів пробного періоду).

Прогулянковий хокер x86 повідомляє мені, що відсутні такі файли DLL:

• API-MS-WIN-CORE-COM-L1-1-0.DLL
• API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
• API-MS-WIN-CORE-WINRT-L1-1-0.DLL
• API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
• API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
• API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
• DCOMP.DLL
• GPSVC.DLL
• IESHIMS.DLL

Я переглянув ці файли DLL API-MS-WIN -... і виявив, що вони фактично вже повинні бути частиною Windows 7 (хоча деякі сайти, які заявляють, що належать до Windows 8 та Windows Server 2012).

Я вже спробував запропоновані нами виправлення, які є:

• працює 'sfc / scannow'
• встановлення виконавчих файлів Visual Studio 2008 SP1

Але це нічого не вирішило. :-(

Бічна примітка: У моєму вікні розробки їх також немає, і, здається, вони не потребують. Наприклад, user32.dll у моєму вікні не посилається на один із них, тоді як установка на VMware робить.

Будь-яка ідея, як виправити це питання? Я спробував знайти відповідне завантаження / виправлення на сторінках Microsoft, але не вдалося.

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

Насправді всі DLL-файли, про які повідомляється, відсутніми інструментом Dependency Walker, а саме такі

* API-MS-WIN-CORE-...

Файли DLL типу не були частиною фактичної проблеми.

У моєму випадку реєстрація трьох файлів OCX відсутня, і після цього все було просто нормально, але інструмент Walker Dependency Walker все ще перераховував усі ті самі файли DLL, що і раніше, навіть коли програма тільки зараз працює нормально.

Суть цього: Як зазначав хтось інший, інструмент на сьогоднішній день трохи застарів і не завжди працює належним чином з новою ОС. Таким чином, тримайте очі відкритими і не вводите в оману, пропускаючи "API-MS-WIN-CORE-COM-L1-1-0.DLL", ... проблема, ймовірно, лежить повністю в іншому місці.

Ця проблема пов'язана з відсутністю "перерозподільного пакета" Visual Studio. Не очевидно, якого з них не вистачає на основі прогулянки залежністю, але я спробую спершу відповідний вашій версії компілятора і побачити, чи все працює належним чином:

Візуальна студія 2015

Visual Studio 2013

Visual Studio 2010

Visual Studio 2008

Я зіткнувся з цією проблемою, оскільки використовую компілятори Visual Studio, але не повне середовище Visual Studio.

Смію надати тут нове посилання: Останні підтримувані завантаження Visual C ++ . Штейн Есмул, 29.11.2018 .

Я щойно вирішив ту саму проблему з C ++ Qt 5 та Windows 7 64 бітами з MSCVC 2012.

На початку я думав, що це проблема файлів MSLC / Windows DLL, але, як сказав Борис, проблема була в моїх проектних залежностях. Ключ - " Як дізнатися про залежність вашого проекту в Qt 5? ".

Оскільки я не знайшов чіткого способу це знати ( Уокер Залежності не дуже мені допоміг ...), я дотримувався наступної "зворотної процедури", яка займає не більше 5 хвилин, і уникаю багато головних болів при DLL залежність файлів:

1. Складіть свій проект і перенесіть виконуваний файл у порожню папку: myproject.exe
2. Спробуйте виконати його, воно виявить помилку (відсутні файли DLL ...).
3. Тепер скопіюйте всі файли DLL з Qt (у моєму випадку вони були у C: \ Qt \ Qt5.1.1 \ 5.1.1 \ msvc2012_64_opengl \ bin) у цю папку.
4. Спробуйте виконати ще раз, це, ймовірно, буде добре.
5. Почніть поступово видаляти і намагайтеся кожен раз, коли ваш виконуваний файл все ще працює, намагаючись залишити мінімально необхідні файли DLL.

Якщо у вас є всі DLL-файли в одній папці, то простіше знайти, який з них недійсний (XML, WebKit, ... що б там не було ..), і, отже, цей спосіб не займає більше п'яти хвилин.

Я просто вирішив ту саму проблему.

Залежність Уокер в цьому випадку вводить в оману і змушує мене втрачати час. Отже, список "відсутніх" файлів DLL з першого повідомлення не є корисним, і ви, ймовірно, можете його проігнорувати.

Рішення полягає в тому, щоб знайти, які посилання викликає ваш проект, і перевірити, чи дійсно вони встановлені на сервері.

@Ben Brammer, не важливо, які три файли .ocx відсутні, оскільки вони відсутні лише для проекту Лео Т Авраама. Ваш проект, ймовірно, викликає інші файли DLL.

У моєму випадку це були не три .ocx файли, але відсутній файл DLL-з'єднувача MySQL. Після встановлення MySQL Connector для .NET на сервері проблема зникла.

Отже, коротше кажучи, рішення таке: перевірте, чи всі посилання на ваш проект є.

Як вже згадувалося, DCOMP є частиною перерозподілюваних VC ++ (реалізуючи час виконання OpenMP) і є єдиним істинно відсутнім компонентом. Все інше - помилкові повідомлення.

Зокрема, API-MS-WIN-XXXX.DLL - це набори API - по суті, додатковий рівень непрямості виклику запроваджується поступово, починаючи з Windows 7. Розвиток Dependency Walker, здавалося б, зупинився задовго до цього, і він не може правильно працювати з наборами API.

Тож тут нема чого хвилюватися. Ти більше нічого не пропускаєш.

Кращою альтернативою знайти справді потрібні файли DLL, яких немає (якщо це справді проблема) - запустити Monitor Monitor і відступити від відмови, шукаючи послідовності помилок зондів для конкретного файлу DLL у всьому системному шляху.

Я також зіткнувся з цією проблемою, але рішення, яке, здається, є загальною ниткою тут, і я побачив в іншому просторі в Інтернеті, - це "[повторно встановити пакет, що перерозподіляється". Однак для мене це не працює, оскільки проблема виникла під час запуску інсталятора нашого продукту (який встановлює перерозподільний пакет) для тестування нашої блискучої нової версії Visual Studio 2015.

Проблема виникла через те, що перелічені файли DLL не знаходяться у шляху встановлення Visual Studio (наприклад, C: \ Program Files (x86) \ Microsoft Visual Studio 14.0 \ VC \ redist) і тому не були додані до встановлення. Ці апарати api-ms-win- * встановлюються на шлях встановлення SDK для Windows 10 як частина встановлення Visual Studio 2015 (наприклад, C: \ Program Files (x86) \ Windows Kits \ 10 \ Redist).

Установка в Windows 10 спрацювала нормально, але для встановлення на Windows 7 потрібно додати ці DLL-файли до нашого продукту. Для отримання додаткової інформації див. Оновлення для Universal C Runtime у Windows, де описано доповнення цих залежностей, викликаних Visual Studio 2015, та передбачено завантаження для різних платформ Windows; також див. Введення універсальної CRT, яка описує редизайн бібліотек CRT. Особливий інтерес викликає пункт 6 у розділі " Розповсюдження програмного забезпечення", що використовує Універсальну CRT :

Оновлено 11 вересня 2015 року: підтримується локальне розгортання додатків Universal CRT. Щоб отримати бінарні файли для локального розгортання додатків, встановіть комплект для розробки програмного забезпечення Windows (SDK) для Windows 10. Бінарні файли будуть встановлені на C: \ Program Files (x86) \ Windows Kits \ 10 \ Redist \ ucrt. Вам потрібно буде скопіювати всі DLL разом із вашим додатком (зауважте, що набір файлів DLL необхідний, різний у різних версіях Windows, тому ви повинні включити всі файли DLL для того, щоб ваша програма працювала на всіх підтримуваних версіях Windows).

Цей внесок насправді не дає відповіді на початкове запитання, але, беручи до уваги частоту звернень до цього потоку, я припускаю, що існує досить багато людей, які мають справу з проблемою, яку бібліотеки API-MS-WIN-CORE не можуть знайти.

Мені вдалося вирішити проблему, коли моя програма відмовилася починати з повідомлення про помилку про те, що API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL не знайдено шляхом простого оновлення Visual Studio.

Я не думаю, що моє середовище побудови (Windows 7 Pro SP1, Visual Studio Ultimate 2012) було повністю зіпсовано, і воно працювало чудово для більшості моїх проектів. Але за деяких дуже конкретних обставин я отримав повідомлення про помилку (див. Нижче).

Після оновлення Visual Studio 11 з початкової версії CD (я забув шукати номер версії) до версії 11.0.61030.00 Оновлення 4, також зламаний проект запустився знову.

Це вирішило для мене питання:

Видаліть перерозподільний пакет Visual Studio 2010, якщо він уже встановлений, та встановіть Microsoft Windows 7 SDK .

Я вирішив проблему. Коли я зареєстрував файли OCX, я запустив його у вікно команд, яке було виконано як адміністратор.

Для всіх, хто прийшов сюди, але з проблемою Photoshop : моє рішення полягало в видаленні MS VC ++ перерозподілюваного першого x86 і 64 обох. Потім встановіть одну, відповідну версії та архітектурі Windows (86 або 64).

Встановлення SQL Server Management Studio 2014 на щойно встановленій Windows 7 вирішило цю проблему у нашого клієнта після дводенного смішного бою.

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

Я скопіював файл combase.dll (C: \ Windows \ System32) у папку випуску, і це вирішило проблему.

Я прийшов сюди з цією проблемою, після спробу нової установки Windows 7 OEM, оновлення до Windows 10.

Після деяких пошуків форумів Microsoft, і я знайшов таке рішення, яке працювало для мене:

Замініть C:\Windows10Upgrade\wimgapi.dllна той, зC:\Windows\System32\wimgapi.dll

Пропоную також перевірити, скільки пам’яті зараз використовується.

Виявляється, неможливість знайти ці файли DLL була першим симптомом, виявленим при спробі запуску програми (або запустити, або налагодити) у Visual Studio.

Після закінчення півгодини з численними подряпинами в голові, пошуку в Інтернеті, запуску монітора процесів та диспетчера завдань , і залежить, зовсім інша програма, що працює з початку часу, повідомила, що "пам'ять мало; спробуйте зупинити деякі програми" або дещо таке. Після вбивства Firefox, Thunderbird, Process Monitor і все залежить знову.

Тільки для підтвердження відповідей тут, моя резолюція полягала в тому, щоб скопіювати DLL, який не завантажувався, та файл ocx, який додав його до папки system32, що вирішило мою проблему.