windows - Classic ASP: C0000005 Fejl ved udførelse

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg forsøger at udføre klassiske ASP-sider på en Windows 2008 64 bit R2-boks.


Oprindeligt var problemet med at registrere dlls: Det er nu rettet.
Registrer DLL-fil på Windows Server 2008 R2


Nu når jeg forsøger at få adgang til siden, får jeg denne fejl



  Active Server Pages fejl 'ASP 0241'

  
  CreateObject undtagelse

  
  index.asp

  
  CreateObject of '(null)' forårsagede undtagelse C0000005.

  
  Server objekt fejl 'ASP 0177: c0000005'



Når jeg ændrer koden fra Server.CreateObject til CreateObject .. Jeg ender med denne fejl



  Fejl i Active Server Pages 'ASP 0115' Uventet fejl
  index.asp

  
  En trappable fejl (C0000005) opstod i et eksternt objekt. Scriptet kan ikke fortsætte med at køre.



Jeg kontrollerede alt, hvad jeg kunne - Adgang og admin rettigheder mv.
Ansøgningsbassinet er indstillet til No Managed Code + Classic mode.


Eventuelle ideer til at rette op på dette?

Bedste reference


Du vil ikke rette op på dette i ASP. C0000005 er adgangsforbudsundtagelsen. Dette sker, når kode forsøger at læse hukommelse, som den ikke har tildelt.


Dll'en gør noget dårligt, når det laster eller under konstruktionen af ​​objektet.


Har du testet DLL'en med en enkel. VBS-fil?

Andre referencer 1


Jeg havde netop den samme fejl.


I mit tilfælde var fejlen C0000005 forårsaget af manglende afhængighed.


ProcessMonitor hjælper mig med at finde det. (Filtrer efter proces, og tjek 'Navn ikke fundet')
Navn ikke fundet på dll


Kopiering af den nødvendige fil på det rigtige sted løst mit problem. (I mit tilfælde var VB6FR.dll en nødvendig afhængighed af vb6 på fransk.)

Andre referencer 2


Jeg tilbragte flere timer med at jage dette også.


I mit tilfælde blev det forårsaget af genbrug af en recordset objekt flere gange uden at lukke den mellem DB-opkald. Koden arbejdede uden tilsyneladende problem i flere lignende tilfælde, og så stoppede en af ​​dem bare med at tolerere processen.


Fejlen opstod, da jeg forsøgte at lukke recordset i slutningen af ​​siden, hvilket gjorde fejlfinding vanskeligere.


Jeg rydde op koden og sørgede for at recordset blev lukket mellem opkald, og det løste problemet.

Andre referencer 3


For min erfaring bruger du AVG Free, og efter en opdatering fik du denne slags fejl.

Andre referencer 4


Bare kørt ind i den samme fejl under forsøg på at bruge min egen com kontrol og i mit tilfælde viste det sig, at min dll blev kompileret i debug mode.


Der er to måder omkring det:



  1. Kør IIS i fejlsøgningstilstand. For 32 bit bruger du følgende linje:
    C: \ Windows \ SysWOW64 \ inetsrv> w3wp.exe -debug


    Bemærk, at du skal stoppe IIS-tjenesten og for 64 bit bruger du den i System32.

  2. Kompilér en udgivelsesversion :)


Andre referencer 5


Jeg havde samme fejl, mens du lastede csv-fildataene mere end én gang.
Trin 1 - Opret for det første et temp tabel for at overføre csv data til temp tabellen og derefter flytte til hovedbord og slet temp tabel, når data er flyttet. Dette skal gøres programmatisk.


Trin 2 - Gå til mysql og vælg databasen og brug denne forespørgsel (SHOW FULL PROCESSLIST;) brug uden parentes. Dette vil vise dig status for kørende genstande. Hvis du finder noget objekt med status som 'Sove', skal dette ryddes før 2. forsøg på at uploade filen. Normalt er standard ventetiden ca. 28000 sek. Du skal reducere det som pr krav. Koden for at reducere ventetiden er (SET GLOBAL wait\_timeout=5;). Brug uden braketter. Brug dette er mysql. Dette vil genindstille din globale ventetid til 5 sek. (skift efter dine behov). Dette bør løse dit problem. Alt det bedste.

Andre referencer 6


Jeg havde det samme problem, der opstod engang efter KB4093114 blev installeret på en server. (Jeg er ikke 100\% sikker på, at KB forårsagede problemet, men jeg formoder det, fordi scriptmotoren blev opdateret.) [4]


Problemet blev forårsaget af et recordset, der udsender et varchar (max) felt til markeringen. Selvom fejlen ikke angiver et linjenummer, kunne jeg bestemme det for udgangen af ​​feltet varchar (max) gennem forsøg og fejl.


<\%
...
rs.Open "SELECT LongDescription FROM Table1"
while (not rs.EOF)
   \%> <p><\%= rs("LongDescription") \%></p> <\%    ' ERROR HAPPENS BECAUSE OF THIS LINE
   rs.MoveNext
wend
\%>


Fjernelse af denne linje løser problemet. Også at kaste feltet til en ikke-max varchar retter også det:


 rs.Open "SELECT LongDescription = Cast(LongDescription as varchar(4000)) FROM Table1"


For at gøre sager værre fandt jeg, at når fejlen opstår, selvom du retter den , skal du genbruge app poolen for at få fejlen til at gå væk .

Andre referencer 7


Du kan måske tjekke denne blogindlæg med titlen 'Classic ASP (ASP 3.0) virker ikke på 64 bit med 32bit COM objekter' http://blogs.msdn.com/b/robgruen/archive/2005/05/26/422328.aspx[5]


Det er lidt dateret, og forfatteren henviser fejlagtigt til ASP-handleren som et ISAPI-filter (det er en udvidelse, ikke et filter), men ellers virker informationen god.


hvis asp handler kun er samlet som 64bit, vil du ikke kunne indlæse et 32bit COM objekt ind i det, uanset hvad du gør.


forfatteren nævner noget om en COM + løsning. Jeg har en fornemmelse af, at en 32-bit ud af COM + -pakke ville være i stand til at indlæse dette 32bit COM-objekt, og din ASP-side kunne foretage tværgående procesopkald til denne COM + -pakke.


held og lykke,
Mærke