15 svar · 1 025 visningar · startad av Nexus86
PHP has encountered an Access Violation at 01850AFD
Detta fel skrev PHP i varje fil jag hämtade från min egen server. Det började lite tidigare idag. Den enda ändringen jag hade gjort var att sätta zlib.output_compression i php.ini till On för att hjälpa min bandbredd en bit på traven.
Så självklart provade jag att sätta tillbaka det på Off och då fungerar det finfint. Frågan är då bara, varför blir det så?
Nu får jag samma fel utan zlib.output_compression så jag har inte en aning om vad som orsakar det.
Jag använder IIS 6.0 på en Windows Server 2003. Jag ska testa med Apache också får jag se om det fortfarande händer för isåfall är det antagligen en bugg ihop med IIS.
Startade du om servern?
Efter att ha bytt ja. Och varje gång det börjar komma det där felet så startar jag om den igen (det klarar sig några timmar).
En bugg ihop med IIS tror jag inte det handlar om i detta falllet även om stabiliteten lämnar en del övrigt att önska.
php.exe skrev:
PHP has encountered an Access Violation ...
Detta tolkar jag som att PHP försöker komma åt något som den inte har behörighet till. Fil eller mapp.
Försök att gå igenom php.ini och kontrollera alla tänkbara sökvägar, såsom temp-mappar, session-sökvägar, temporär upload, loggar etc. och kontrollera därefter att IIS:en har den behörighet som krävs på dessa mappar och filer.
I och med IIS6 så körs ju webbservern lite säkrare än tidigare och har inte rätt att skriva någonstans till disk.
Även om det fungerat tidigare utan problem så kan det ju bero på nya skript som av någon anledning gör att PHP behöver tillgång till disken eller om du kanske ändrat någon funktion i php.ini som kräver filåtkomst.
Att installer Apache löser med all säkerhet problemet men då har du också en webbserver som kommer åt det mesta som standard.
kjell skrev:
En bugg ihop med IIS tror jag inte det handlar om i detta falllet även om stabiliteten lämnar en del övrigt att önska.
php.exe skrev:
PHP has encountered an Access Violation ...
Detta tolkar jag som att PHP försöker komma åt något som den inte har behörighet till. Fil eller mapp.
Försök att gå igenom php.ini och kontrollera alla tänkbara sökvägar, såsom temp-mappar, session-sökvägar, temporär upload, loggar etc. och kontrollera därefter att IIS:en har den behörighet som krävs på dessa mappar och filer.
I och med IIS6 så körs ju webbservern lite säkrare än tidigare och har inte rätt att skriva någonstans till disk.
Även om det fungerat tidigare utan problem så kan det ju bero på nya skript som av någon anledning gör att PHP behöver tillgång till disken eller om du kanske ändrat någon funktion i php.ini som kräver filåtkomst.
Att installer Apache löser med all säkerhet problemet men då har du också en webbserver som kommer åt det mesta som standard.
Jag har läst att många får Access Violation från PHP med IIS (inte bara 6.0) så jag antog bara att det var en bugg.
Jag ska kolla upp alla sökvägar får jag se sen om det klarar sig. Återkommer med svar. :)
Hade samma problem (dock under Win2k/IIS5), löste sig när jag installerade senaste "stabila" versionen av 4.3 från http://snaps.php.net
Nexus86 skrev:
Jag har läst att många får Access Violation från PHP med IIS (inte bara 6.0) så jag antog bara att det var en bugg.
Det är väl inte omöjligt men först måste man ta reda på vad det beror på.
OlleBoop skrev:
Hade samma problem (dock under Win2k/IIS5), löste sig när jag installerade senaste "stabila" versionen av 4.3
Den här buggen tycks gälla oavsett version av PHP eller Windows. En snabbtitt i rapporteringarna bekräftar att det är många som haft problemet och det gäller från tidiga versioner av PHP till dagens sista snapshot. Av dessa har 99% statusen Bogus vilket jag tolkar som felet inte har fått högsta prioritet.
En intressant detalj är att många i rapporten hävdrar att det löst sig när man installerat en senare (och ibland äldre) version av PHP. I flera av fallen hade det förmodligen löst sig om man installer om samma version och kanske till och med endast lagt till en ny php.ini. Vidare ser man också att flera av dem som löst problemet med en nyinstallation senare återkommer och säger att nu fungerar det inte längre. Om det beror på klåfingerhet elller en potential bugg ska man kanske låta vara osagt.
För att återgå till Nexus86s problem.
Du har inte specificerat vilken version av PHP du kör, vilka extensions du använder eller om du också använder andra komponenter som Zend Studio eller Zend Optimizer. Var det zip- eller exe-versionen som installerades?
Är det samma skript som genererar felet första gången det dyker upp efter en omstart? Finns det flera webbar på servern som använder sessions? Etc.
Helst skulle jag vilja att du tog bort din nuvarande version av PHP med tillhörigheter och gör en ren installation med en ny. Det ska vara zip-versionen och inifilen ska vara recommend. Redogör vart du kopierar beroendefiler och vilka ändringar som görs i inifilen och lägg inte till några extensions mer än möjligen mysql till en början. Det blir enklare att hitta orsaken till problemet om man utgår från en så ren installation som möjligt och tar en sak i taget.
Jag använder PHP 4.3.8 och har inte lagt till någon extra extension eller komponent utan kör med ren PHP (däremot så använder jag mysql men det är ju inte som en extension). Jag installerade zip-versionen. Det är flera sidor som genererar samma fel. Det finns bara en webb på den och den använder inte sessions, bara cookies.
Jag installerade PHP med zip-filen runt den 18e September. Ini-filen är recommend. Men jag testar att installera om PHP nu.
Jag hade felet från 4.36.->4.3.8, efter mycket pillande med rättigheter och php.ini gav jag slutligen upp och installerade senaste stabila "builden" av 4.3 och problemet försvann.
Det roliga är att problemet utstod med 4.3.7 OCH att det kvarstod vid tillbakagång till 4.3.6 (samma php.ini).
Klåfingrig eller ej, nu är felet borta och det verkar hålla i sig (uppgraderade till 4.3.9 igår).
Jag installerade just 4.3.9 och ska se hur det flyter på. Än så länge verkar det funka. :)
Mina filer:
- php-zippen uppackad i C:\php
- php4isapi.dll kopierad till C:\WINDOWS\System32 varifrån jag även kör det
- php4ts.dll kopierad till C:\WINDOWS\System32
- php.ini-recommended kopierad till C:\WINDOWS\php.ini
Ändingar i php.ini:
- error_reporting = E_ALL & ~E_NOTICE
- error_log = c:\phplog.log
- doc_root = c:\wwwroot
- upload_tmp_dir = c:\php\uploadtemp
Rättigheter:
- c:\phplog.log = full rättighet
- c:\php\uploadtemp = full rättighet
- c:\WINDOWS\php.ini = läsa, köra
- c:\WINDOWS\System32\php4isapi.dll = läsa, köra
- c:\WINDOWS\System32\php4ts.dll = läsa, köra
Något jag missat?
Tackar! Det funkar fint när jag installerade PHP 4.3.9 så jag stannar nog hos IIS. :)
Bra att det fungerar :)
Nexus86 skrev:
Något jag missat?
Nä det borde rimligen fungera. Jag noterar dock att du lagt en sökväg i doc_root men jag har för mig att man i så fall måste ha safe_mode påslaget om det ska gälla.
Det är inget fel att installer på det här sättet men tänkte ändå redogöra för hur jag brukar göra. Jag har haft minst bekymmer med PHP efter den här modellen.
Jag ser inte anledningen till att sprida ut filerna i diverse systemmappar m.m. mer än möjligen att det kanske är enklare att få igång det hela. Därefter är det mest ett gissel vid felsökning, uppgraderingar och ominstallationer när filerna ligger lite här och där.
En liten guide för att får igång PHP 4.3.* på Windows 2003 Server:
Har man många domäner så har jag märkt att det kan bli en del problem om dessa har sessionstyrda inloggningar och man exempelvis loggar in från den ena till en annan domän med samma webbläsarfönster. Därför kör jag alltid en egen session-mapp för varje domän. Sedan brukar jag trixa lite med session.gc_probability och session.gc_divisor om man har lågtrafikerade sidor som använder sessions.
Vi får hoppas att du slipper problemet nu efter din nya installation men helt stabilt är inte PHP på den här plattformen, dock acceptabelt för de flesta behoven. Jag har en server där jag kör Zend WinEnabler (betalversion) och där har jag inte haft de, förhållandevis, få problem som uppstår med den fria versionen. Tycker däremot att den var väldigt krävande vad gäller systemresurser och speciellt påtagligt blir det om man har välbesökta sidor så det är inget jag vill rekommendera.
Lägger till inifilen i registret. Detta görs genom att i registret gå till HKEY_LOCAL_MACHINE\SOFTWARE\ och skapa en nyckel med namnet PHP och därefter markera denna och skapa ett strängvärde innehållande c:\php
Det måste man väl inte göra om man har c:\php (eler var man nu la php) i PATH?
PHP fungerar men i phpinfo() får man inte korrekt sökväg till inifilen om man inte anger den i registret. Förmodligen för att den som standard söker ett viss antal troliga sökvägar men den registrerar inte vart den hämtas utan tar bara för givet att den finns i c:\windows
Jag tycker det är bättre att tala om vart den ska söka för det kan ju hända att man har haft tidigare installationer (slarvigt avinstallerade) med inifiler i windows eller system32 och då kanske den inte tar den fil som man förväntar sig.
Förvisso, speciellt om man gått från gamla installationssättet med kopiering av filer till systemkatalogen till det nya med c:\php i PATH.
