Detta felmeddelande visas av Microsoft Windows Installer Engine (undrar du vad är det här? Läs här) och är en allmän felkod som indikerar att ett problem inträffade under installationen. Läs i den här artikeln för att lära dig hur du går bortom denna hastighetsstöt. Följande är den troliga listan över kända orsaker till att detta fel inträffar:
- Skapandet av kort filnamn är inaktiverat på måldatorn.
- En anpassad åtgärd för Installationsskript prototypas felaktigt.
- En fil är låst och kan inte skrivas över.
- Microsoft Windows Installer Service är inte korrekt installerad.
- Windows Temp-mappar är fulla.
- Installationen var skadad efter installationen och misslyckades därför med detta fel under avinstallationen.
- En äldre version av Install Shield Developer används.
- Skriv- och fildelning är inte installerat om din applikation behöver det.
Felsökning 1603 MSI-fel
Som diskuterat, The 1603 felkod returneras oftast när någon åtgärd misslyckas under en installation i Windows, och oftast indikerar den att en av de anpassade åtgärderna i MSI misslyckades. När vi stöter på en misslyckad installation med returkod 1603, här är stegen som vi bör följa:
Kör om installationen med detaljerad loggning aktiverad med steg som liknar dem som listas här.
Steg 1: Skapa en detaljerad loggfil med namnet msi * .log i% temp% -katalogen nästa gång installationspaketet körs. (Klicka här om du vill veta fler sätt att skapa logg). Lär dig mer om kommandoradsväxlarna här.
msiexec / i < msipath > setup.msi /l*vc:\temp\msi.log
Steg 2: Öppna den detaljerade loggen i en text redigerare som anteckningsblock och sök efter strängen ”returvärde 3”. I nästan alla fall kommer detta att ta oss till avsnittet i den detaljerade loggen som visar den åtgärd som misslyckades och som ursprungligen orsakade återställning av installationen.
Steg 3: Granska innehållet i loggfilen omedelbart ovanför strängen ”returvärde 3” för att avgöra vilken anpassad åtgärd eller standardåtgärd som misslyckades. Beroende på vilken åtgärd som misslyckas måste vi gå vidare till mer detaljerad felsökning härifrån.
Man kan upptäcka att det största hindret för att felsöka en misslyckad installation ofta nollställer vilken del av installationen som faktiskt är misslyckas, och det här tricket att söka efter ”returvärde 3” hjälper till att påskynda processen i nästan alla fall. Naturligtvis fungerar det inte i 100% av scenarierna.
Du kan hitta några sätt att felsöka loggarna här –
”Få tillgång till dina favoritapplikationer från din Android / iOS-enhet med ett virtuellt skrivbord av CloudDesktopOnline.com-one av de bästa skrivbordet som tjänsteleverantörer. Få en gratis testversion av Office 365 och utmärkt support av O365CloudExperts.com ”
Kända lösningar
Följande lösningar har löst det här felet i de flesta fall:
- Se till att skapandet av kort filnamn är aktiverat på målmaskinen. Du kan kontrollera att målmaskinen inte har inaktiverat kortfilnamn. genom att navigera till följande registerpost:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
Se till att värdet ”NtfsDisable8dot3NameCreation” är lika med 0. Detta indikerar att kort filnamnskapande är aktiverat. Värdet 1 indikerar att denna funktion är inaktiverad. Du bör ändra värdet till 0. Efter att ha ändrat detta värde bör målmaskinen startas om innan du försöker starta installationen igen.
Obs! Om målmaskinen bör normalt ha inaktiverat kort filnamn, den kan inaktiveras efter installationen genom att återställa ”NtfsDisable8dot3NameCreation” till 1 och starta om. - För att säkerställa att Windows Installer-tjänsten är korrekt installerad och konfigurerad, rekommenderas att användare installerar filen InstmsiA.exe på Windows 95/98 / Me eller InstmsiW.exe på Win NT-system. Dessa filer levereras med din InstallShield-produkt och finns på följande plats: < Produktväg > \ Redist \ Language Independent \ i386. Om tjänsten är installerad, att veta status för tjänstexektionen kan du också gå till services.msc i kommandotolken, kontrollera status för Windows Installer Service. ”St upping och starta om det kan hjälpa ”
- Töm alla tillfälliga mappar. De specifika tillfälliga mapparna för en maskin kan bestämmas genom att komma åt DOS-prompten och skrivuppsättningen.Observera värdena som anges för TEMP och TMP och ta bort alla filer på dessa platser.
- Se till att inga andra program, inklusive verktyg som virusscannrar, körs i bakgrunden. Stäng alla program och verktyg som kör och starta installationen igen.
- Om detta fel inträffar under avinstallationen använder du verktyget Microsoft Windows Installer CleanUp för att avinstallera installationen. När installationen har avinstallerats framgångsrikt kan du sedan felsöka projektet för att avgöra vad som orsakade det ursprungliga felet.
Om det inte faller i det sista kan det vara något annat fel som inträffade under installationen, uppdatera i kommentarerna..låt fixa det ..!
LinkedIn och andra diskussioner
Jag hade också lagt upp detta på LinkedIn Discussions och har fått lite kvalitetssvar för samma sak – jag kommer att extrahera lite information därifrån och lägga upp den här så att du kan få all information på en enda plats.
En Senior Desktop Analyst, skriver Jack Fei,
Vijay har några utmärkta poäng om hur man felsöker dessa typer av problem. Från min erfarenhet är korrigeringen vanligtvis trivial när du förstår ”hur man korrelerar detaljerade loggningsresultat” med msi-interna.
Först vet du att ”installation” betyder msiexec.exe sekventiellt bearbetar rader i InstallExecuteSequence-tabellen inuti msi-databasen.
För det andra, vet att msiexec.exe bearbetar kommandona sekvenserade mellan InstallInitialize och InstallFinalizes i två pass. Ett sätt att tänka på är det första passet ”installerar ändringen villkorligt” till maskinen medan du kontrollerar syntaxen för kommandot och det andra passet ”överför ändringen till maskinen”. En 1603 betyder i huvudsak ”ett fel inträffade” och försökte begå ändringen, vilket orsakade att msiexec.exe ”backade ändringen”.
Denna typ av fel orsakas antingen av msi-misteknik (de flesta leverantörs-msi är felteknikerade) eller av ett ”maskinspecifikt problem”. Så Patrick Pepin ger ett utmärkt förslag att kontrollera msi-leverantören.
Att ha VMWare eller bildverktyg hjälper verkligen till att felsöka denna typ av problem.
1 Jag skulle bestämma att problemet kan reproduceras på en ren maskin med alla nödvändiga förutsättningar installerade (bara för att eliminera möjligheten att falskt negativt orsakas av testning på en okänd eller korrupt datormiljö).
2. Om det är en fångst-msi (originalkällan är icke-msi) Jag skulle systematiskt utesluta filer och registernycklar tills jag isolerade komponenten som orsakade problemet i min msi. Jag byggde den, så jag vet bäst hur jag fixar den.
3. om msi konstruerades av en annan leverantör skulle jag granska den detaljerade loggen och isolera den felaktiga instruktionen i InstallExecuteSequenceTab le. Min huvudsakliga teknik var att hitta felet som genererade ”1603” -felet och hitta den troliga instruktionen som orsakade det. För att testa min teori skulle jag bara kommentera den instruktionen (sätta ett negativt tecken i sekvenskolumnen) och kör kommandot igen Ibland hade jag tur och till och med ”kringgett” msi-defekten genom att lämna den anpassade åtgärden kommenterad. Den här typen av ändringar fungerar bra när den anpassade åtgärden gör ”onödiga kontroller” för stationära datorer i dina miljöer. Självklart skulle jag ”testa den modifierade msi” och se till att programmet installerades och startar rent.
4 . Om jag kan reproducera problemet på ett rent skrivbord kommer jag att ha bra ammunition för att kontakta säljaren. Men min erfarenhet är att om du vet hur du gör det jag har skisserat kommer du att uttömma de tekniska supportavdelningarna för vilken leverantör du än ringer. Detta görs av ”politiska skäl” mer än någonting annat – så du kan vara hjälten när säljaren trots betydande uthållighet från dig inte kan hitta en lösning.
Lycka till. Hoppas det hjälper.
