bug in 1.2.14 ? - IIS web crash down

Topics: Developer Forum, User Forum
Jul 17, 2008 at 9:16 PM
this is what we got:

Source: WAM
ID: 204

...Error in ISAPI-Application
msw3prt + 0xAA6B
msw3prt + 0xC2CA
msw3prt + 0xD83A
msw3prt + 0x807E
msw3prt + 0x83E3
msw3prt + 0x870A
msw3prt + 0x87A0
msw3prt!GetExtensionVersion + 0x5E9
msw3prt + 0x7881
 + 0x7E003B

Is this a bug?
Do you have a stable version?
What can we do to avoid the web crashs down?
Should we mail you the ini-file?
We need help very quickly it's urgent.
Thanks for your help.
Jul 19, 2008 at 3:06 PM
Sorry, I don't know what it is that you sent me.
If IIRF is crashing, it sure looks like a bug.

But I'm not going to be able to help you without more information.
when does it crash?  Under what conditions?  Do you have a log file?
etc etc
Jul 20, 2008 at 12:30 PM
thanks for your answer.
A log-file doesn't exit, cause the error can't be reproduced.

This is the ini-file:

IterationLimit 5

RewriteRule ^/xdomianx_forum/list_msg_date.php3(.*)$ http://www.xdomianx.de/MAMainLeserforum.asp [R]
RewriteRule ^/xdomianx_forum/detail_msg.php3(.*)$ http://www.xdomianx.de/MAMainLeserforum.asp [R]
RewriteRule ^/xdomianx_forum/list_msg_thread.php3(.*)$ http://www.xdomianx.de/MAMainLeserforum.asp [R]
RewriteRule ^/sixcms/detail.php\?id=(.*)$ http://www.xdomianx.de/MAMainFachartikelarchivDetail.asp?artikelid=$1 [R]
RewriteRule ^/sixcms/detail.php(.*)$ http://www.xdomianx.de/MAMainFachartikelarchiv.asp [R]
RewriteRule ^archiv.xdomianx.de/ma/live/fachartikelarchiv/ha_news/detail/(.*)$ http://www.xdomianx.de/MAMainNews.asp [R]
RewriteRule ^/sixcms/list.php(.*)$ http://www.xdomianx.de/MAMainProduktinformation.asp [R]
RewriteRule ^/ma/live/fachartikelarchiv/ha_news/detail/(.*).html$ http://www.xdomianx.de/MAMainFachartikelarchivDetail.asp?artikelid=$1 [R]
RewriteRule ^/ma/live/fachartikelarchiv/ha_artikel/detail/(.*).html$ http://www.xdomianx.de/MAMainFachartikelarchivDetail.asp?artikelid=$1 [R]

Is it possible that rule 4, 8 and 9 does create the error.

Is this fixed in 1.2.15a? Thanks for help.


Jul 22, 2008 at 1:15 AM
Edited Jul 22, 2008 at 11:02 PM

very odd.

It's very urgent, but you cannot reproduce the problem?
If it's not recurring, is it really that urgent?

You wrote:  "A log-file doesn't exit, cause the error can't be reproduced."

I guess you did not have logging turned on when the error occurred?  Is that right?

I cannot say if rule 4, 8 and 9 cause the error.

Also I cannot say if it is fixed in 1.2.15a, because we still don't know what the problem is. 

Your ini file seems fairly simple; it could be a basic problem in the redirect logic.  But without a way to reproduce it, I'm sure I won't be able to fix it.
Can you run a load test with this ruleset and see if you can reproduce it in a test environment? 

Jul 23, 2008 at 11:57 AM
ok, we tested in der enviroment.
No error, no crash down.
But in the real life on the productiv server sometimes (avg 1 til 3 time per week) the IIS crashs with the ISAPI-error.

The problem is that we don't know at what time the server is down, so we have to install another program that brings the server up.
Not really professionell.
We suppose that some urls which are in the google index have a format which brings the server down.
But how can we found it.

I think we have to switch on the Log-file.

Are you sure that the log-file logs the error?
Which log-level do you prefer 3 or 4?
Thanks for your help.
Jul 23, 2008 at 4:27 PM
Edited Jul 23, 2008 at 4:28 PM

I'm sorry you're having trouble. I agree  that it is not very professional to have an unreliable web system.

I suggest you enable the IIRF logging until we are able to learn  more about the problem.

I cannot guarantee that turning on logging will give us a clear indication of the error, but it will tell us much more than we have now.

I would prefer level 4 logging to start with. 

Also, you said that You suspect that there are some URLs in the google index which cause the problem. What makes you say this?
Could it be that you are getting attacked?  That someone is sending you poorly formatted URLs?

Before you turn on IIRF logging, Can you have a look in the IIS logs - which are normally in c:\windows\system32\LogFiles ??
You may look in the IIS logs to see if you can find suspiscious URLs, or the last URL before the filter crashes.  (Not sure if IIS will log it before the filter dies though).  

Thank you.