Windows 7, wersja 64-bitowa, problemy z biblioteką DLL

Mam problem z naszym plikiem wykonywalnym. Korzystam z tego 32-bitowego pliku C ++ na moim 64-bitowym pudełku programistycznym Windows 7, który ma również wszystkie te aplikacje Microsoft (Visual Studio 2008 + 2010, TFS, SDK, Microsoft Office) ... I nadal działa dobrze.

Teraz dostałem instalację klienta tego samego programu i zostałem poproszony o przetestowanie go przy użyciu czystej instalacji systemu Windows 7. Tak więc dostałem 64-bitowy VMware dla Windows 7 i zaktualizowałem go do Windows 7 SP 1 (ta sama wersja, którą tunuje moje okno programisty). Ale podczas gdy na moim pudełku programisty wszystko jest w porządku, program nie działa z pudełkiem VMware (30-dniowa wersja próbna).

Walker zależności x86 mówi mi, że brakuje następujących plików 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

Poszukałem tych plików DLL API-MS-WIN -... i stwierdziłem, że powinny one już być częścią systemu Windows 7 (niektóre witryny twierdzą, że należą do systemu Windows 8 i Windows Server 2012).

Próbowałem już sugerowanych poprawek, które znalazłem:

• uruchamianie „sfc / scannow”
• instalowanie plików wykonywalnych programu Visual Studio 2008 z dodatkiem SP1

Ale to niczego nie rozwiązało. :-(

Uwaga dodatkowa: Moje pudełko rozwojowe też ich nie ma i wydaje się, że ich nie potrzebuje. Na przykład user32.dll na moim urządzeniu nie łączy się z jednym z nich, podczas gdy instalacja na VMware tak.

Masz pomysł, jak rozwiązać ten problem? Próbowałem znaleźć odpowiedni plik do pobrania / naprawy na stronach Microsoft, ale nie udało mi się.

Po rozwiązaniu problemu chciałem zgłosić to, co się dowiedziałem, i nie mogę opublikować tego jako odpowiedzi, ponieważ pytanie zostało zamknięte.

Właściwie wszystkie pliki DLL zgłoszone przez narzędzie Dependency Walker zginęły, a mianowicie te

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

Pliki DLL typu nie były częścią rzeczywistego problemu.

W moim przypadku brakowało rejestracji trzech plików OCX, a potem wszystko było w porządku, ALE narzędzie Dependency Walker nadal wyświetlało te same pliki DLL, co wcześniej, nawet gdy program działał już dobrze.

Istota tego: jak ktoś inny stwierdził, narzędzie jest już trochę przestarzałe i nie zawsze działa poprawnie z nowszym systemem operacyjnym. Dlatego miej oko otwarte i nie daj się zwieść brakując „API-MS-WIN-CORE-COM-L1-1-0.DLL”… problem prawdopodobnie leży gdzie indziej.

Ten problem jest związany z brakiem „pakietu redystrybucyjnego” programu Visual Studio. Nie jest oczywiste, którego brakuje, na podstawie ścieżki zależności, ale najpierw spróbuję tej, która odpowiada twojej wersji kompilatora i zobaczę, czy wszystko działa poprawnie:

Visual Studio 2015

Visual Studio 2013

Visual Studio 2010

Visual Studio 2008

Natknąłem się na ten problem, ponieważ korzystam z kompilatorów Visual Studio, ale nie pełnego środowiska Visual Studio.

Odważę się wstawić nowy link tutaj: Najnowsze obsługiwane pliki do pobrania Visual C ++ . Stein Åsmul, 29.11.2018 .

Właśnie rozwiązałem ten sam problem z C ++ Qt 5 i Windows 7 64 bity z MSCVC 2012.

Na początku myślałem, że jest to problem z plikiem MSVC / Windows DLL, ale jak powiedział BorisP, problemem były moje zależności projektowe. Kluczem jest „ Jak poznać zależności projektu od Qt 5? ”.

Ponieważ nie znalazłem żadnego jasnego sposobu, aby to wiedzieć ( Dependency Walker nie bardzo mi pomógł ...), poszedłem następnie za „odwrotną procedurą”, która zajmuje nie więcej niż 5 minut i pozwala uniknąć wielu problemów z biblioteką DLL zależności plików:

1. Skompiluj projekt i przenieś plik wykonywalny do pustego folderu: myproject.exe
2. Spróbuj go uruchomić, odzyska błąd (brakujące pliki DLL ...).
3. Teraz skopiuj wszystkie pliki DLL z Qt (w moim przypadku były one w C: \ Qt \ Qt5.1.1 \ 5.1.1 \ msvc2012_64_opengl \ bin) do tego folderu.
4. Spróbuj wykonać ponownie, prawdopodobnie będzie dobrze działać.
5. Zacznij stopniowo usuwać i próbuj za każdym razem, gdy plik wykonywalny nadal działa, starając się pozostawić minimum niezbędnych plików DLL.

Gdy wszystkie pliki DLL znajdują się w tym samym folderze, łatwiej jest ustalić, który z nich jest nieprawidłowy (XML, WebKit, ... cokolwiek ...), w związku z czym ta metoda nie zajmuje więcej niż pięć minut.

Właśnie rozwiązałem ten sam problem.

Zależność Walker wprowadza w błąd w tym przypadku i spowodował, że straciłem czas. Tak więc lista „brakujących” plików DLL z pierwszego postu nie jest pomocna i prawdopodobnie możesz ją zignorować.

Rozwiązaniem jest znalezienie, które referencje są twoje wywołuje projekt i sprawdzenie, czy są one naprawdę zainstalowane na serwerze.

@Ben Brammer, nie jest ważne, których brakuje trzech plików .ocx, ponieważ brakuje ich tylko w projekcie Leo T. Abrahama. Twój projekt prawdopodobnie wywołuje inne pliki DLL.

W moim przypadku nie były to trzy pliki .ocx, ale brak pliku DLL konektora MySQL. Po zainstalowaniu konektora MySQL dla platformy .NET na serwerze problem zniknął.

Krótko mówiąc, rozwiązaniem jest: sprawdź, czy są tam wszystkie odniesienia do twojego projektu.

Jak wspomniano, DCOMP jest częścią redystrybucji VC ++ (implementującej środowisko wykonawcze OpenMP) i jest jedynym naprawdę brakującym komponentem. Cała reszta to fałszywe raporty.

W szczególności API-MS-WIN-XXXX.DLL to zestawy API - w zasadzie dodatkowy poziom pośrednictwa połączeń wprowadzany stopniowo od Windows 7. Dependency Walker Rozwój najwyraźniej na długo przed tym i nie może poprawnie obsługiwać zestawów API.

Więc nie ma się o co martwić. Nie stracisz nic więcej.

Lepszą alternatywą do znalezienia naprawdę potrzebnych plików DLL, które brakuje (jeśli rzeczywiście jest to problem), jest uruchomienie Monitora procesu i cofnięcie się od awarii, szukając sekwencji nieudanych sond dla określonego pliku DLL na całej ścieżce systemowej.

Zetknąłem się również z tym problemem, ale rozwiązaniem, które wydaje się tutaj być powszechnym wątkiem, i widziałem gdzie indziej w Internecie, jest „[re] zainstaluj pakiet redystrybucyjny”. Jednak dla mnie to nie działa, ponieważ problem pojawił się podczas uruchamiania instalatora naszego produktu (który instaluje pakiet redystrybucyjny) w celu przetestowania naszych nowych, błyszczących kompilacji Visual Studio 2015.

Problem pojawił się, ponieważ wymienione pliki DLL nie znajdują się w ścieżce instalacji programu Visual Studio (na przykład C: \ Program Files (x86) \ Microsoft Visual Studio 14.0 \ VC \ redist) i dlatego nie zostały dodane do instalacji. Te biblioteki api-ms-win- * są instalowane w ścieżce instalacyjnej zestawu Windows 10 SDK jako część instalacji programu Visual Studio 2015 (np. C: \ Program Files (x86) \ Windows Kits \ 10 \ Redist).

Instalacja w systemie Windows 10 działała dobrze, ale instalacja w systemie Windows 7 wymagała dodania tych plików DLL do naszej instalacji produktu. Aby uzyskać więcej informacji, zobacz Aktualizacja dla Universal C Runtime w systemie Windows, która opisuje dodanie tych zależności spowodowanych przez Visual Studio 2015 i zapewnia pobieranie dla różnych platform Windows; zobacz także Wprowadzenie do uniwersalnego CRT, który opisuje przeprojektowanie bibliotek CRT. Szczególnie interesujący jest punkt 6 w sekcji zatytułowanej Oprogramowanie dystrybucyjne korzystające z Universal CRT :

Zaktualizowano 11 września 2015: obsługiwane jest lokalne wdrożenie Universal CRT w lokalnej aplikacji. Aby uzyskać pliki binarne do wdrożenia lokalnego dla aplikacji, zainstaluj Windows Software Development Kit (SDK) dla systemu Windows 10. Pliki binarne zostaną zainstalowane w C: \ Program Files (x86) \ Windows Kits \ 10 \ Redist \ ucrt. Będziesz musiał skopiować wszystkie biblioteki DLL za pomocą aplikacji (pamiętaj, że zestaw plików DLL jest konieczny, jest różny w różnych wersjach systemu Windows, więc musisz dołączyć wszystkie pliki DLL, aby program mógł działać na wszystkich obsługiwanych wersjach Windows).

Ten wkład tak naprawdę nie odpowiada na początkowe pytanie, ale biorąc pod uwagę wskaźnik trafień tego wątku, zakładam, że sporo osób zajmuje się problemem, że nie można znaleźć bibliotek API-MS-WIN-CORE.

Udało mi się rozwiązać problem polegający na tym, że moja aplikacja odmówiła uruchomienia z komunikatem o błędzie, że nie można znaleźć API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL, po prostu aktualizując Visual Studio.

Nie sądzę, że moje środowisko kompilacji (Windows 7 Pro SP1, Visual Studio Ultimate 2012) zostało całkowicie pomieszane, działało dobrze dla większości moich projektów. Ale w niektórych bardzo szczególnych okolicznościach dostałem komunikat o błędzie (patrz poniżej).

Po zaktualizowaniu programu Visual Studio 11 z początkowej wersji dysku CD (zapomniałem sprawdzić numer wersji) do wersji 11.0.61030.00 Aktualizacja 4 również uszkodzony projekt uruchomił się ponownie.

To rozwiązało problem:

Odinstaluj pakiet redystrybucyjny Visual Studio 2010, jeśli już go zainstalowałeś, a następnie zainstaluj zestaw Microsoft Windows 7 SDK .

Rozwiązałem problem. Kiedy zarejestrowałem pliki OCX, uruchomiłem je z oknem poleceń, które zostało wykonane jako administrator.

Dla każdego, kto tu przyszedł, ale ma problem z Photoshopem : moim rozwiązaniem było odinstalowanie najpierw redystrybucyjnej wersji MS VC ++ x86 i 64. Następnie zainstaluj jeden odpowiedni dla wersji i architektury systemu Windows (86 lub 64).

Instalacja programu SQL Server Management Studio 2014 na świeżo zainstalowanym systemie Windows 7 rozwiązała ten problem u naszego klienta po dwudniowej śmiesznej bitwie.

Miałem ten sam problem. Po spędzeniu wielu godzin na wyszukiwaniu w sieci znalazłem rozwiązanie dla siebie.

Skopiowałem plik combase.dll (C: \ Windows \ System32) do folderu wydania i rozwiązał problem.

Przybyłem tutaj z tym problemem, po wypróbowaniu nowej instalacji OEM systemu Windows 7 i aktualizacji do Windows 10.

Po przeszukaniu forów Microsoft i podobnych znalazłem następujące rozwiązanie, które działało dla mnie:

Zamień C:\Windows10Upgrade\wimgapi.dllna ten zC:\Windows\System32\wimgapi.dll

Sugeruję również sprawdzenie, ile pamięci jest aktualnie używane.

Okazuje się, że niemożność znalezienia tych plików DLL była pierwszym objawem występującym podczas próby uruchomienia programu (uruchomionego lub debugowanego) w programie Visual Studio.

Po ponad pół godziny z dużym drapaniem głowy, przeszukiwaniem sieci, uruchamianiem Monitora procesów i Menedżera zadań , i to zależy, zupełnie inny program, który działał od początku czasu, zgłosił, że „pamięć jest niska; spróbuj zatrzymać niektóre programy” lub niektóre takie. Po zabiciu Firefoksa, Thunderbirda i Monitora procesu, i wszystko zależy, wszystko znów działało.

Aby potwierdzić odpowiedzi tutaj, moją decyzją było skopiowanie nie ładującego się pliku DLL ORAZ pliku ocx, który mu towarzyszył, do folderu system32, który rozwiązał mój problem.