Denne feilmeldingen vises av Microsoft Windows Installer Engine (Lurer du på hva er dette? Les her) og er en generell feilkode som indikerer at det oppstod et problem under installasjonen. Les på denne artikkelen for å lære hvordan du kan gå bort fra denne fartsdumpen. Følgende er den sannsynlige listen over kjente årsaker til at denne feilen oppstår:
- Oppretting av kort filnavn er deaktivert på målmaskinen.
- En tilpasset handling for Install Script er prototypet feil.
- En fil er låst og kan ikke overskrives.
- Microsoft Windows Installer Service er ikke riktig installert.
- Windows Temp-mappene er fulle.
- Oppsettet ble ødelagt etter installasjonen og mislykkes derfor med denne feilen under avinstallasjon.
- En eldre versjon av Install Shield Developer brukes.
- Deling av utskrift og fildeling er ikke installert hvis applikasjonen din trenger det.
Feilsøking 1603 MSI-feil
Som diskutert, The 1603 feilkode returneres for det meste når en handling mislykkes under en installasjon på Windows, og oftest indikerer det at en av de tilpassede handlingene i MSI mislyktes. Når vi støter på et mislykket oppsett med returkode 1603, er det trinnene vi bør følge:
Kjør oppsettet på nytt med detaljert logging aktivert ved å bruke trinn som ligner på de som er oppført her.
Trinn 1: Generer en detaljert loggfil kalt msi * .log i% temp% katalogen neste gang installasjonspakken kjøres. (Klikk her for å vite flere måter å generere logg på). Lær mer om kommandolinjebryterne her.
msiexec / i < msipath > setup.msi /l*vc:\temp\msi.log
Trinn 2: Åpne den detaljerte loggen i en tekst redaktør som notisblokk og søk etter strengen «returverdi 3». I nesten alle tilfeller vil dette ta oss til seksjonen i den detaljerte loggen som viser handlingen som mislyktes, og som opprinnelig førte til at tilbakestillingen ble opprettet.
> Trinn 3: Gjennomgå innholdet i loggfilen rett over «returverdi 3» -strengen for å bestemme hvilken tilpasset handling eller standardhandling som mislyktes. Avhengig av hvilken handling som mislykkes, må vi gå videre til mer detaljert feilsøking herfra.
Man kan finne at den største hindringen for feilsøking av et mislykket oppsett ofte er å nullstille hvilken del av oppsettet som faktisk er mislykkes, og dette trikset med å søke etter «returverdi 3» ender opp med å øke hastigheten på denne prosessen i nesten alle tilfeller. Selvfølgelig fungerer den ikke i 100% av scenariene.
Du kan finne noen måter å feilsøke loggene på her –
«Få tilgang til dine favoritt Windows-applikasjoner fra Android / iOS-enheten din med et virtuelt skrivebord av CloudDesktopOnline.com-one av de beste stasjonære tjenesteleverandørene. Få en gratis prøveversjon av Office 365 og utmerket støtte fra O365CloudExperts.com «
Kjente løsninger
Følgende løsninger har løst denne feilen i de fleste tilfeller:
- Forsikre deg om at opprettelse av kort filnavn er aktivert på målmaskinen. Du kan kontrollere at målmaskinen ikke har opprettet kort filnavn. ved å navigere til følgende registeroppføring:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
Forsikre deg om at verdien «NtfsDisable8dot3NameCreation» er lik 0. Dette indikerer at opprettelse av korte filnavn er aktivert. Verdien 1 indikerer at denne funksjonaliteten er deaktivert. Du bør endre verdien til 0. Etter å ha endret denne verdien, må målmaskinen startes på nytt før du prøver å starte oppsettet på nytt.
Merk: Hvis målmaskinen skal normalt ha deaktivert kort filnavn, den kan deaktiveres etter at installasjonen er fullført ved å tilbakestille «NtfsDisable8dot3NameCreation» til 1 og starte den på nytt. li> For å sikre at Windows Installer Service er riktig installert og konfigurert, anbefales det at brukere installerer filen InstmsiA.exe på Windows 95/98 / Me eller InstmsiW.exe på Win NT-systemer. Disse filene leveres med InstallShield-produktet ditt og er lokalisert på følgende sted: < Produktsti > \ Redist \ Language Independent \ i386. Hvis tjenesten er installert, å vite status for tjenesteekseksjonen, kan du også gå til services.msc i ledeteksten, sjekke statusen til Windows Installer Service. «St opping og starte den på nytt kan hjelpe ”- Tøm alle midlertidige mapper. De spesifikke midlertidige mappene for en maskin kan bestemmes ved å få tilgang til DOS-ledeteksten og typesettet.Legg merke til verdiene som er oppført for TEMP og TMP, og slett alle filene på disse stedene.
- Forsikre deg om at ingen andre applikasjoner, inkludert verktøy som virusscannere, kjører i bakgrunnen. Lukk alle applikasjoner og verktøy som kjører, og start installasjonen på nytt.
- Hvis denne feilen oppstår under avinstallasjon, kan du bruke Microsoft Windows Installer CleanUp-verktøyet til å avinstallere installasjonen. Når installasjonen er vellykket avinstallert, kan du feilsøke prosjektet for å finne ut hva som forårsaket den opprinnelige feilen.
Hvis den ikke faller inn i dette siste, kan det være andre feil som oppstod under installasjonen, oppdater i kommentarene … la oss fikse det ..!
LinkedIn og andre diskusjoner
Jeg hadde også lagt ut dette på LinkedIn Discussions og har fått noen kvalitetsresponser for det samme – Jeg vil hente ut litt informasjon derfra og legge det ut her slik at du kan få all informasjonen på ett sted.
En Senior Desktop Analyst, skriver Jack Fei,
Vijay har noen gode poeng om hvordan du feilsøker denne typen problemer. Fra min erfaring er løsningen vanligvis triviell når du først har forstått «hvordan man kan korrelere detaljerte loggeresultater» med msi-interne.
Først må du vite at «installasjon» betyr at msiexec.exe sekvensielt behandler rader i InstallExecuteSequence-tabellen inne msi-databasen.
For det andre, vet at msiexec.exe behandler kommandoene sekvensert mellom InstallInitialize og InstallFinalizes i to passeringer. En måte å tenke på det er det første passet som «installerer endringen betinget» til maskinen mens du sjekker syntaksen til kommandoen, og det andre passet «overfører endringen til maskinen». En 1603 betyr i hovedsak «en feil oppstod» og prøvde å begå endringen, noe som fikk msiexec.exe til å «backout endringen».
Denne typen feil er enten forårsaket av misi-ingeniørarbeid (de fleste leverandør-MSI-maskiner er feilengineered) eller av et «maskinspesifikt problem». Så Patrick Pepin gir et utmerket forslag til å sjekke msi-leverandøren.
Å ha VMWare eller bildebehandlingsverktøy hjelper virkelig med å feilsøke denne typen problemer.
1 Jeg vil bestemme at problemet kan reproduseres på en ren maskin med alle forutsetninger installert (bare for å eliminere muligheten for falsk negativ forårsaket av testing på et ukjent eller korrupt pc-miljø).
2. Hvis det er en fangst-msi (original kilde er ikke-msi) Jeg vil systematisk ekskludere filer og registernøkler til jeg isolerte komponenten som forårsaket problemet i min msi. Jeg bygde den, så jeg vet best hvordan jeg skal fikse den.
3. Hvis msi ble konstruert av en annen leverandør, ville jeg gjennomgå den detaljerte loggen og isolere den mislykkede instruksjonen i InstallExecuteSequenceTab le. Min viktigste teknikk var å finne feilen som genererte «1603» -feilen og finne den sannsynlige instruksjonen som forårsaket den. For å teste teorien min, vil jeg bare kommentere den instruksjonen (sette et negativt tegn i sekvenskolonnen) og kjøre kommandoen på nytt Noen ganger ville jeg være heldig og til og med «jobbe» rundt msi-feilen ved å la den egendefinerte handlingen kommentere. Denne typen endringer fungerer bra når den egendefinerte handlingen gjør «unødvendige kontroller» for stasjonære datamaskiner i miljøene dine. Selvfølgelig vil jeg «teste den modifiserte msi» og sørge for at applikasjonen er installert og starter på en ren måte.
4 . Hvis jeg kan gjengi problemet på et rent skrivebord, vil jeg ha god ammunisjon til å kontakte leverandøren. Min erfaring er imidlertid at hvis du vet hvordan du gjør det jeg har skissert, vil du tømme teknisk supportavdelingene til den leverandøren du ringer. Dette gjøres av «politiske grunner» mer enn noe annet – så du kan være helten når leverandøren til tross for betydelig utholdenhet fra deg, ikke finner en løsning.
Lykke til. Håper dette hjelper.
