I have a solution running in a shared environment, and according to the hosting it causes the app pool to crash. But unfortunately they cannot provide me with any detailed description of what is happening.
Is there any kind of way I can log what's going on ?
I can't even install a package since the website is completely down. My only option is to get a complete backup and get it running locally so I can keep an eye on it.
The hosting provider gave me this:
Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0
Problem signature:
P1: w3wp.exe
P2: 7.5.7600.16385
P3: 4a5bcd2b
P4: clr.dll
P5: 4.0.30319.225
P6: 4d53688b
P7: c00000fd
P8: 00001ac6
P9:
P10:
Attached files:
C:\Windows\Temp\WER870A.tmp.appcompat.txt
C:\Windows\Temp\WER8778.tmp.WERInternalMetadata.xml
C:\Windows\Temp\WER8779.tmp.hdmp
C:\Windows\Temp\WERBC8E.tmp.mdmp
These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_w3wp.exe_40bf615d915ce0c0542cceabb829d8592c368fd9_cab_7e4abfc6
Analysis symbol:
Rechecking for solution: 0
Report Id: 0fff1082-8533-11e0-99d1-5c260afc8bfe
Report Status: 4
----
Faulting application name: w3wp.exe, version: 7.5.7600.16385, time stamp: 0x4a5bcd2b
Faulting module name: clr.dll, version: 4.0.30319.225, time stamp: 0x4d53688b
Exception code: 0xc00000fd
Fault offset: 0x00001ac6
Faulting process id: 0x17484
Faulting application start time: 0x01cc193fcfd95799
Faulting application path: C:\Windows\SysWOW64\inetsrv\w3wp.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Report Id: 0fff1082-8533-11e0-99d1-5c260afc8bfe
Did you have a fully working website? If so do you remember all the packages you installed?
If you used an sql database or mysql then you could try checking your umbraco log table. It may give us more information to work out what is going on.
When I first started using my shared hosting I kept forgetting to change the framework version that the apppool used and so it would crash and completely lock me out and the only way I could fix it was to rename the web.config file using ftp.
So I've been looking in the log table and to me it looks pretty ok except for the huge amount of login/logout posts. The client called me today at 13:32 asking if I was messing around, I wasn't, and the site has been down since.
The logs starts at 13.00 today until now
Can anyone see if there is something wrong out of this. Any help would be appreciated
I've made 2 log files, with and without login/logout posts.
I've experienced this in the past with XSLT scripts that end up in never ending loops. Basically they continue to run up the quantity of memory they use and the app pool recycles, then it happens again and again and the app pool does what it should and switches it's self off and you get the Service Unavailable message
I cant remember exact code for when this happens but if you run the site locally and hit all the pages sooner or later this issue raises it's head and at that point you should know what page it's on.
I experienced this the other day in an XSLT file when using apply-templates
This code would kill the App Pool from time to time, once the App pool was down I cold restart it but it would still just crash the app pool again
<xsl:template match="value" mode="content">
<xsl:if test="normalize-space()">
<xsl:apply-templates select="umbraco.library:GetXmlNodeById(text())" />
</xsl:if>
</xsl:template>
<xsl:template match="*[@isDoc]">
<!--This match here would sometimes crash the app pool-->
Render the content
</xsl:template>
This code has been fine
<xsl:template match="value" mode="content">
<xsl:if test="normalize-space()">
<!--Rendering the content here without apply-templates has been fine-->
</xsl:if>
</xsl:template>
This happen on sites which were running fine until a few nodes were deleted, then the App Pool crashes happened (using the Apply Templates code)
Technically the XSLT above is fine, so if you find any XSLT that's causing the problem please post it back here as it may be a bug with Umbraco which needs to be reported.
Here's a scenario that will cause an infinite loop: You have a simple template that matches Media "Image" elements, and then you do this:
<xsl:template match="/">
<!-- Should return an <Image> element -->
<xsl:apply-templates select="umbraco.library:GetMedia(/macro/pageImage, false())"/>
</xsl:template>
<!-- Template for images -->
<xsl:template match="Image">
<img src="{umbracoFile}" width="{umbracoWidth}" />
</xsl:template>
This works great, as long as there exist a media Image with the requested id (in the macro parameter pageImage) - the GetMedia() call returns an XML chunk like this:
But if the media item is deleted (or the id just doesn't exist), the GetMedia() call will return a chunk of XML that looks like this:
<error>No media is maching '1239'</error>
(Yes, complete with the typo and all :-) - but the problem is that the XPathNodeIterator (or so I'm told it's called) isn't pointing to the <error> element, rather, it points to the document element, which means that the template that gets applied is the root template - the one matching "/", which in turn calls GetMedia() once again, and then there goes the memory...
You can circumvent this by making sure only to apply templates to the returned node if it doesn't have an error element, like this:
My biggest problem, right now, is actually that I don't have a local test server. Everytime I send the webserver into a loop, while debugging, I have to wait 29 minutes before the app pool recycles.
So I think I'll give my girlfriend an iPad 2 and then convert her Mac mini to my test server.
Any kind of crash log
I have a solution running in a shared environment, and according to the hosting it causes the app pool to crash.
But unfortunately they cannot provide me with any detailed description of what is happening.
Is there any kind of way I can log what's going on ?
I'm not a C# developer, just a simple frontender.
You can install http://our.umbraco.org/projects/backoffice-extensions/falm-housekeeping and view the Umbraco logs via the Umbraco interface.
The hosting provider should have access to the windows logs related to your app pool.
Rich
I can't even install a package since the website is completely down.
My only option is to get a complete backup and get it running locally so I can keep an eye on it.
The hosting provider gave me this:
Hi Sebastian,
Did you have a fully working website? If so do you remember all the packages you installed?
If you used an sql database or mysql then you could try checking your umbraco log table. It may give us more information to work out what is going on.
When I first started using my shared hosting I kept forgetting to change the framework version that the apppool used and so it would crash and completely lock me out and the only way I could fix it was to rename the web.config file using ftp.
Ben
So I've been looking in the log table and to me it looks pretty ok except for the huge amount of login/logout posts.
The client called me today at 13:32 asking if I was messing around, I wasn't, and the site has been down since.
The logs starts at 13.00 today until now
Can anyone see if there is something wrong out of this. Any help would be appreciated
I've made 2 log files, with and without login/logout posts.
umbracolog with login/logout
umbracolog without login/logout
I've experienced this in the past with XSLT scripts that end up in never ending loops. Basically they continue to run up the quantity of memory they use and the app pool recycles, then it happens again and again and the app pool does what it should and switches it's self off and you get the Service Unavailable message
I cant remember exact code for when this happens but if you run the site locally and hit all the pages sooner or later this issue raises it's head and at that point you should know what page it's on.
I experienced this the other day in an XSLT file when using apply-templates
This code would kill the App Pool from time to time, once the App pool was down I cold restart it but it would still just crash the app pool again
<xsl:template match="value" mode="content"> <xsl:if test="normalize-space()"> <xsl:apply-templates select="umbraco.library:GetXmlNodeById(text())" /> </xsl:if> </xsl:template> <xsl:template match="*[@isDoc]"> <!--This match here would sometimes crash the app pool--> Render the content </xsl:template>This code has been fine
<xsl:template match="value" mode="content"> <xsl:if test="normalize-space()"> <!--Rendering the content here without apply-templates has been fine--> </xsl:if> </xsl:template>
This happen on sites which were running fine until a few nodes were deleted, then the App Pool crashes happened (using the Apply Templates code)
Rich
So far so good.
It seems, as you guys say, to be my XSLT that's fucked up.
Let the digging begin ;)
Thanx alot for your help guys
Technically the XSLT above is fine, so if you find any XSLT that's causing the problem please post it back here as it may be a bug with Umbraco which needs to be reported.
Rich
Hi all,
Here's a scenario that will cause an infinite loop: You have a simple template that matches Media "Image" elements, and then you do this:
<xsl:template match="/"> <!-- Should return an <Image> element --> <xsl:apply-templates select="umbraco.library:GetMedia(/macro/pageImage, false())"/> </xsl:template> <!-- Template for images --> <xsl:template match="Image"> <img src="{umbracoFile}" width="{umbracoWidth}" /> </xsl:template>This works great, as long as there exist a media Image with the requested id (in the macro parameter pageImage) - the GetMedia() call returns an XML chunk like this:
<Image id="1239" nodeName="..." ...> <umbracoFile>/media/76293/filename.png</umbracoFile> <umbracoWidth>230</umbracoWidth> ... </Image>But if the media item is deleted (or the id just doesn't exist), the GetMedia() call will return a chunk of XML that looks like this:
(Yes, complete with the typo and all :-) - but the problem is that the XPathNodeIterator (or so I'm told it's called) isn't pointing to the <error> element, rather, it points to the document element, which means that the template that gets applied is the root template - the one matching "/", which in turn calls GetMedia() once again, and then there goes the memory...
You can circumvent this by making sure only to apply templates to the returned node if it doesn't have an error element, like this:
/Chriztian
Great post Chriz ... thanx alot.
This was excatly the problem ... ;)
My biggest problem, right now, is actually that I don't have a local test server.
Everytime I send the webserver into a loop, while debugging, I have to wait 29 minutes before the app pool recycles.
So I think I'll give my girlfriend an iPad 2 and then convert her Mac mini to my test server.
Sounds like an excellent idea :-)
/Chriztian
is working on a reply...