App Pool crashes

Topics: Developer Forum
Jan 17, 2009 at 1:49 AM
I'm not sure if this is an IIRF issue, but some some other related posts here that didn't end in resolution, so I'm posting it here to see if cheeso or anyone else has some insight.

We have been experiencing this vague issue for weeks now. But it has recently become much more frequent. What we are seeing is that the website starts loading really slowly. It gets slower and slower over time until finally it stops loading pages, and throws an error. The errors that we're getting are Sql Server timeout issues, however the DB Server is not showing high CPU or memory usage. I don't actually think it is a query optimization issue, but possibly a contention of available connections to the DB server (just a guess). We recently made a switch on the DB server to Snapshot Isolation Level to reduce data/query contention, since we do not need up-to-the-second accuracy of our data. We do not believe this to be related to our issue, but do not want to rule out that possibility. Instead, what I'm seeing is a lot of SQL timeout exceptions on the website, but also this odd error in the System event logs showing this:
===============================
Event Type: Warning Event
Source: W3SVC
Event Category: None
Event ID: 1011
Date: 1/16/2009
Time: 5:17:36 PM
User: N/A
Computer: WEB2
Description: A process serving application pool 'dotNET Pool' suffered a fatal communication error with the World Wide Web Publishing Service. The process id was '9096'. The data field contains the error number. ================================

It seems that I can temporarily resolve the issue by recycling our application pool. Once completely recycled, the website is screaming fast and works well for a while, until it gradually starts to load pages slower and slower, eventually leading to this error above. For a while we were seeing this error multiple times per minute. I've recently made another change (in attempts to narrow down our problems and see if we can figure out what is going on) to switch the SessionState mode on our main website from SqlServer to the StateServer. I've started the ASP.NET session state server service and have the website now running ok with the SessionState service handling all traffic sessions. This has helped somewhat, but we are still seeing the events pasted above, now every few minutes instead of multiple times per minute.

I've done a bit of research and have come up with a few potential areas to focus on.
http://www.developmentnow.com/g/59_2005_4_0_0_374160/IIS6-and-SP1--Application-Pools-crashing.htm
http://www.codeplex.com/IIRF/Thread/View.aspx?ThreadId=11358

Jan 19, 2009 at 6:05 PM
Edited Jan 19, 2009 at 6:53 PM
I have run the DebugDiagnostic IIS tools and come up with these crash reports, showing that IsapiRewrite4.dll caused a stack overflow exception. It looks like I'm using version 1.2.13, do I need to upgrade to fix this issue? Could be one of my rules that is causing this problem? 

I do have the .ini and .dll in a separate directory (C:\IIRF\) so it's not the metabase locking issues I've encountered before (http://www.codeplex.com/IIRF/Thread/View.aspx?ThreadId=10123)


WARNING - DebugDiag was not able to locate debugsymbols for IsapiRewrite4.dll, so the information below may beincomplete.

Inw3wp__PID__7288__Date__01_18_2009__Time_08_13_35PM__933__Second_Chance_Exception_C00000FD.dmpthe assembly instruction at IsapiRewrite4!TerminateFilter+d03a inC:\IIRF\IsapiRewrite4.dll has caused a stack overflow exception(0xC00000FD) when trying to write to memory location0x00f82e08 on thread 7
Please follow up with the vendor forC:\IIRF\IsapiRewrite4.dll

Also, to help diagnose, here is my ini file of filters and rules.

RewriteLog  D:\IISLogs\Ionic\iirfLog.out
RewriteLogLevel 0

MaxMatchCount 10
IterationLimit 10

NotParsed ^/(.*).(jpg|gif|png|ico|js|css|axd|aspx)(\?(.*))?$
NotParsed ^/(.*).axd(\?)?d=(.*)$
NotParsed ^/(.*).aspx$

# REDIRECTS - not URL Rewrites
RewriteRule  ^/addvenue /Venues/AddVenue.aspx [I,R]
RewriteRule  ^/addfestival /Festivals/AddFestival.aspx [I,R]
RewriteRule  ^/festivals/festivalguide.aspx /Festivals/ [I,R]
RewriteRule  ^/addshow /Shows/AddShow.aspx [I,R]
RewriteRule  ^/bugs /About/Contact/Bugs.aspx [I,R]
RewriteRule  ^/community /Fans [I,R]
RewriteRule  ^/unsubscribe /MyProfile/Unsubscribe/Unsubscribe.aspx [I,R]
RewriteRule  ^/(addband|addartist) /Artists/AddArtist.aspx [I,R]
RewriteRule  ^/(addstory|addarticle) /Articles/AddStory.aspx [I,R]
RewriteRule  ^/(fix|fixform|corrections) /About/Contact/Fix.aspx [I,R]

#profile filters -- /profiles/andy -> /fans/andy#
RewriteRule  ^/profiles/(\w+).aspx(.*)$ /fans/$1.aspx$2 [I,U]
RewriteRule  ^/profiles/([\w\d\s\.]+)(.aspx){0}/?$ /fans/AtAGlance.aspx?UN=$1 [I,U]
#profile filter -- /fans/andy
RewriteRule  ^/fans/((?>([^?/\n]|/[^.?/\n])+)(?<!\.aspx))(/?)$ /fans/ataglance.aspx?un=$1 [I,U,L]

#catch /artist/id/name/PAGE#
RewriteRule  ^/artists/(\d+)/((?>([^?/\n])+)(?<!\.aspx))/?(shows|articles|fans|chatter|bio|links|store)/?$ /artists/$4.aspx?artistID=$1&a=$2 [I,U,L]

#exceptions for "goods" goes to "store.aspx" and "forum" goes to "chatter.aspx"#
RewriteRule  ^/artists/(\d+)/((?>([^?/\n])+)(?<!\.aspx))/?(goods)/?$    /artists/store.aspx?artistID=$1&a=$2 [I,U,L]
RewriteRule  ^/artists/(\d+)/((?>([^?/\n])+)(?<!\.aspx))/?(forum|forums)/?$    /artists/chatter.aspx?artistID=$1&a=$2 [I,U,L]

#only catches /artist/id/name -- if there is a /page at the end, it is caught by a previous rule above.#
RewriteRule  ^/artists/(\d+)/((?>([^?/\n]|/[^.?/\n])+)(?<!\.aspx))(/?)$ /artists/artist.aspx?artistID=$1&a=$2 [I,U,L]
RewriteRule  ^/bands/(\d+)/((?>([^?/\n]|/[^.?/\n])+)(?<!\.aspx))(/?)$ /artists/artist.aspx?artistID=$1&a=$2 [I,U,L]

RewriteRule  ^/artists/([-\w\d]+)/?$ /Search/Results.aspx?Search=$1&More=ArtSch&us=1 [I,U,L]
RewriteRule  ^/bands/([-\w\d]+)/?$ /Search/Results.aspx?Search=$1&More=ArtSch&us=1 [I,U,L]

RewriteRule  ^/articles/(\d+)/((?>([^?/\n])+)(?<!\.aspx))/(\d+)/?  /articles/story.aspx?storyID=$1&pagenum=$4 [I,U,L]
RewriteRule  ^/articles/(\d+)/((?>([^?/\n])+)(?<!\.aspx))/? /articles/story.aspx?storyID=$1 [I,U,L]
Jan 20, 2009 at 2:02 AM
Edited Jan 20, 2009 at 2:04 AM
I've upgraded my filter to use the new version, 1.2.15 R3. This has not resolved the issue, though given me a different exception.

I am desperate for a solution here and am hoping to hear from Cheeso or anyone on this issue soon. I've got my entire web app reliant on these rewritten URLs, so disabling it is not an option. I'm considering making a switch to Helicon Tech's ISAPI_Rewrite here http://www.helicontech.com/download-isapi_rewrite.htm
Anyone seen these exceptions before? Anyone had an experience with this other product? 


WARNING - DebugDiag was not able to locate debug symbols for IsapiRewrite4.dll, so the information below may be incomplete.

In w3wp__PID__4552__Date__01_19_2009__Time_05_56_17PM__277__Second_Chance_Exception_C00000FD.dmp the assembly instruction at IsapiRewrite4!pcre_exec+12f9 in C:\IIRF1.2.15\IsapiRewrite4.dll has caused a stack overflow exception (0xC00000FD) when trying to write to memory location 0x00f82be8 on thread 4
Please follow up with the vendor for C:\IIRF1.2.15\IsapiRewrite4.dll

WARNING - DebugDiag was not able to locate debug symbols for IsapiRewrite4.dll, so the information below may be incomplete.

In w3wp__PID__5320__Date__01_19_2009__Time_05_53_58PM__12__Second_Chance_Exception_C00000FD.dmp the assembly instruction at IsapiRewrite4!pcre_exec+12f9 in C:\IIRF1.2.15\IsapiRewrite4.dll has caused a stack overflow exception (0xC00000FD) when trying to write to memory location 0x01012be8 on thread 7
Please follow up with the vendor for C:\IIRF1.2.15\IsapiRewrite4.dll
WARNING - DebugDiag was not able to locate debug symbols for IsapiRewrite4.dll, so the information below may be incomplete.

In w3wp__PID__5420__Date__01_19_2009__Time_05_55_00PM__246__Second_Chance_Exception_C00000FD.dmp the assembly instruction at IsapiRewrite4!pcre_exec+12f9 in C:\IIRF1.2.15\IsapiRewrite4.dll has caused a stack overflow exception (0xC00000FD) when trying to write to memory location 0x01012be8 on thread 7
Please follow up with the vendor for C:\IIRF1.2.15\IsapiRewrite4.dll

WARNING - DebugDiag was not able to locate debug symbols for IsapiRewrite4.dll, so the information below may be incomplete.

In w3wp__PID__6760__Date__01_19_2009__Time_05_43_49PM__887__Second_Chance_Exception_C00000FD.dmp the assembly instruction at IsapiRewrite4!pcre_exec+12f9 in C:\IIRF1.2.15\IsapiRewrite4.dll has caused a stack overflow exception (0xC00000FD) when trying to write to memory location 0x01012be8 on thread 7
Please follow up with the vendor for C:\IIRF1.2.15\IsapiRewrite4.dll
Jan 21, 2009 at 7:50 PM
Edited Jan 21, 2009 at 8:01 PM
I have figured out what was causing my problems, but since cheeso does not seem to be monitoring or supporting IIRF much anymore, I'll give you the run-down of what happened for others to find.

The issue comes in with some Spam bot problems we've been having. Users are automating regitsrants and creating porn/rington/pharmacy landing pages. Then they go out and mass-post links on forums and blogs to these landing pages they've created on our site. Problem is a lot of the links are malformed and contain garbled up HTML inside the URL. Then the google bot crawls it and see these links and tries to access them. A sample link is like this: 
/Fans/Debt_Cons%20%3Cbr%3E%20%3Cimg%20src='./image/face/bitimg32.gif'%20border=0%20alt='208.85.181.34'%3E%20%3Cb%3Epayday%20loan%20ye%3C/b%3E%20(%3Ca%20href=

But because this link is so wacky, it has caused an exception in IIRF. I'm not exactly sure WHY there is the exception, as I didn't get the stack trace, but presumably because of the length of the URL is larger than the allocated pointer it's trying to store it in? The exception occurs because one of my filter rules actually does catch this URL and tries to rewrite it. And because it's caught it and I have the U flag on, it tries to store this URL in memory and the exception occurs. This exception in IIRF causes the AppPool process to fail and respawn, which in turn causes a major slow down in our site, since 1/4 of the web garden processes is now trying to respawn itself.  If you have only 1 process per AppPool, this is even worse since no requests can be served while the process is restarting. Because the bot was crawling our site, we were getting a LOT of requests for pages like this which was killing our processes left and right and causing the website to crawl to a halt.

What I've done is create some generic URL rewriting filters to catch these bogus URL's and return a 404 status.  For the time being this has reduced the amount of w3wp.exe process failures, but not resolved them completely.  I may end up moving to a new URL Rewrite filter product.

It seems this should be a bug reported and I'll file one. I wonder what the max length of a URL IIRF can store? 
Jan 28, 2009 at 8:40 AM
Hi Mase,

Many thanks for your lengthy and in-depth description of your issue with IIRF. Currently, I'm evaluating IIRF, in thhe process of implementing it on my dev machine. It seems like IIRF is not capable to handle with elementary issues like spam bot sending people bogus URLs. What my understanding is that with IIRF it is relatively easy to crash someones web app, just make sure to send a lot of bogus HTTP requests with wacky URLs and IIRF stops playing?

I'm considering Helicons product now... Is this the right decision?

Thnx again, Lars
Jan 29, 2009 at 6:57 PM
DutchBoy,

I'm not sure if it's the right decision for you. To be fair, I have used the IIRF filter for almost 2 years now and usually without problems. We get some decent traffic volume (5m page views per month) and it has done well until this issue came up. It does seem fairly basic to be able to handle very long URL's, which I believe is the real issue here. I am still running in to this issue on this thread, but not nearly as often. I will soon need to revisit and may eventually migrate to Helicon.

I did have one other issue previously, here: http://www.codeplex.com/IIRF/Thread/View.aspx?ThreadId=26503

I think the most real issue that I have had is that the project has lost pretty much all support. Cheeso was the sole creator of the project and I don't think he checks here for discussions or help anymore. If you need help and support in a time of issues with IIRF, then you may want to just bite bullet and spend the money to get Helicon's filter.


Feb 5, 2009 at 10:41 PM
HI Mase,

1.2.15 R3 has a nasty bug with long URLs.  I traced it down, then notice that 1.2.15 R5 is available.  The 1.2.15 R5 release did fix the bug I found.  You might give it a try
Feb 8, 2009 at 8:34 PM
Hi Mase;

1.2.15 R5 also has a bug that appears on IIS7 (but not IIS6).  In GetServerVariable(), ctx sometimes is NULL.
Here is the fix I made:

  IirfRequestContext *ctx = (IirfRequestContext *) pfc->pFilterContext;
  LogMessage(5,"GetServerVariable: special variable name");
  // sometimes ctx is NULL
  if(ctx != NULL){
   if ((ctx->Magic == IIRF_CONTEXT_MAGIC_NUMBER) && (ctx->PhysicalPath!=NULL))  {
    strcpy_s(pszBuf,DEFAULT_BUFFER_SIZE,ctx->PhysicalPath);
    cbBuf= strlen(ctx->PhysicalPath);
   }
   else {
    strcpy_s(pszBuf,DEFAULT_BUFFER_SIZE,VariableName);
    cbBuf= strlen(pszBuf);
   }
  }
  else {
   strcpy_s(pszBuf,DEFAULT_BUFFER_SIZE,VariableName);
   cbBuf= strlen(pszBuf);
  }
  // end fix

Feb 9, 2009 at 7:01 PM
cfneedham,

Thanks for your posts recently!  I certainly appreciate it. I am very VERY glad to hear that the long URLs bug has been resolved in R5. I will give that one a shot.

Luckily, I'm running IIS 6, so I hope not to see that recent bug.
Feb 10, 2009 at 2:07 AM
cfneedham,

Damn, I notice that R5 is not really setup for a "release" yet... I'd rather not take that risk of installing something that was only simply committed to source control. I've got a high volume site and I don't really want to mess with building the files and crap.  I need the assemblies so I can do a quick swap of .dll files on my server.

I really wish there were more developers involved in this project so that it could get some more attention. Cheeso has done a great job so far, but it feels like he's not doing much more work on the product anymore.
Feb 10, 2009 at 5:20 AM
Hi Mase;

I didn't realize that the assemblies were not posted.  I always modified the source for changes I think are needed.  I did diff the R3 and R5 release and feel that Cheeso fixed bugs and didn't add any.  I guess if you want assembles, then you don't need info about where to patch R3 to fix the long URL bug.  I run IIRF on 6 servers with about 600 sites.  Last week I installed my first 2008 server.  The first few days were full of app pool crashes, but after I installed R5 and the patch I listed earlier, I haven't experianced any more app pool crashes (in 4 days).

Cheeso is busy with his Zip project http://www.codeplex.com/DotNetZip.  I'm sure he'll stop back by here at somepoint if someone ask him nicely.

Fred
Jun 18, 2009 at 11:21 PM

cfneedham (or Cheeso),

When you were seeing these errors where ctx is null, what is the error you saw?

I finally downloaded the source of the 1.2.15R5, rebuilt and deployed, but I'm still seeing the errors. I'll have to run that IIS debug diagnostic tool again to find out what is going on, but wondered what the event log entry looked like for those errors you mentioned. My issues must be different because I'm on IIS6 and you mentioned this bug only existed in IIS7.

I wonder what's going on? Could it be my rules? I have tested the hell out of these things, but I guess it only takes one URL that I didn't test to mess something up. However, I thought if my rules don't match then it will just pass the request on.

I'm still seeing these errors:

===============================
Event Type: Warning Event
Source: W3SVC
Event Category: None
Event ID: 1011
Date: 1/16/2009
Time: 5:17:36 PM
User: N/A
Computer: WEB2
Description: A process serving application pool 'dotNET Pool' suffered a fatal communication error with the World Wide Web Publishing Service. The process id was '9096'. The data field contains the error number. ================================

Jul 1, 2009 at 5:28 PM

ok -- that last post was fubared.

HI Maze;

It has been a while since the errors so I don't exactly remember.  I did find another bug in R5 that would happen on IIS6.  Because Cheeso hasn't implemented the last fix I posted, I didn't post this bug fix.

In GenerateReplacementString(), a buffer overflow occurs when substutions cause the oringinal URL + the substitions to exceed INTERNET_MAX_URL_LENGTH.  This occured for me when I used a get and pasted urlencoded information from a textarea.  The textarea had cr/lf ($0c/$0d) and the substition went wild.  This caused a buffer overflow and aplication pool failure.

Since you are now compiling your own you can implement this fix.

The fix is to check after each non-substitute character for buffer exceeded.  At about line 2500

// pass through
*pOut= *p1;
pOut++;
}
p1++;
// step over the char, either ($ or %) or a non-flag char
========================= new code starts here ==================================
if(INTERNET_MAX_URL_LENGTH <= (int)(pOut-outString)+2){<font size="2">
outString[INTERNET_MAX_URL_LENGTH-1]=
'\0';
LogMessage(4,"URL too long after substitution:%s",outString);<font size="2">
break;
}
========================= new code ends here ==================================
}
*pOut='\0';

 

Jul 1, 2009 at 5:30 PM

one more time -- without the font tags

// pass through
*pOut= *p1;
pOut++;
}
p1++;// step over the char, either ($ or %) or a non-flag char
========================= new code starts here ==================================
if(INTERNET_MAX_URL_LENGTH <= (int)(pOut-outString)+2){
outString[INTERNET_MAX_URL_LENGTH-1]=
'\0';
LogMessage(4,"URL too long after substitution:%s",outString);
break;
}
========================= new code ends here ==================================
}
*pOut='\0';

 

Jul 1, 2009 at 6:16 PM

cfneedham,

I haven't run into that buffer overflow error, but I will keep that in mind moving forward.

I found out (from Cheeso at StackOverflow.com) that the exception is being caused by an infinite loop of rewrites. My output URL is being caught again and again and rewritten over and over. I thought this was protected by the Iteration Limit setting, but that is not the case.

I am now going through my rules to find the culprit rules causing a loop.

Thanks for your fixes!

Coordinator
Jul 2, 2009 at 2:41 AM

The iteration limit is the number of times the set of rules is processed on a given request.

The problem you described on StackOverflow.com, Mase, has to do with a broken regex.   See http://www.pcre.org/pcre.txt and search for "infinite loop". 

It is possible to create other infinite loops, too.

Best bet is to use the TestDriver.exe program when testing incoming URLs.

The readme tells you how to do this.

Jul 2, 2009 at 6:37 PM

Thank you so much for jumping in here, Cheeso.

I have been using the TestDriver.exe program. And ever since I got your response on StackOverflow.com I have been testing hundreds and hundreds of URLs. I've gone into the IIS log files, pulled out ALL URL's requested around the time that the App Pool crashed and reported a fatal error in the System Event Log. Then I strip out the URL's from the IIS Logs and dump them into a SampleUrls.txt file using my live INI rules and run TestDriver.exe. I pipe the output into another file and look through which URL's were rewritten. Then take the resulting rewritten URL's and run those through the TestDriver as well. That seems to be the best approach I can take to find URL's that are getting rewritten over and over and over. (right?)

However, so far - I haven't found any URL's that are getting rewritten more than once.

I thought (wrongly, apparently) that after a URL was rewritten (not redirected), that the ISAPI filter would pass it onto IIS instead of sending the URL back to the beginning of the life cycle, forcing it through the ISAPI filter again. But I certainly don't have the best understanding of how the IIS request cycle works. I can see how a Redirect must send the output URL through the ISAPI filter again, but not a rewrite.

I wonder, in thinking about how to create a solution for this, if it would be possible to have a custom server variable as part of the Http Context to track this. This variable would hold the number of times a URL has been rewritten by IIRF. One URL enters the ISAPI filter with 0 rewrites, and if a rule is matched, it exits the ISAPI filter with the value of 1. Then it will enter the ISAPI filter again and it will know that this URL had been rewritten on it's prior request. Each rewrite increments the value, or creates it if it doesn't exist. This could be one way to avoid a stack overflow exception with an infinite PCRE loop.

Either way, I'm still plugging through my test URL's trying to find the culprit that is getting caught in this rewrite loop.

Any other advice or direction is appreciated!

Coordinator
Jul 5, 2009 at 10:34 PM

I'm sorry, this discussion is getting very long and nested, and I'm having trouble following it anymore. I think maybe there were 3 or 4 problems discussed here on this thread, which is now 6 months old. Then there is at least one other problem discussed somewhere else (stackoverflow.com) which seems to be unrelated. I understand that you have crashes, and you want to solve them. But I'm having trouble keeping up with what we are talking about.

Starting with that, let me see if I can add some clarity.

The IterationLimit  specifies the number of times the set of rules is processed on a request, and the iteration is performed by IIRF, not by IIS.  from the readme:

When a URL is matched to a RewriteRule pattern, the default behavior of IIRF is to recurse - to apply the rules again, iteratively, until no pattern matches. (This behavior can be modified using the [L] flag). In other words, the output of a RewriteRule, is processed as input. The IterationLimit ini-file directive specifies how many times the rewrite filter will loop on a single URL. After a URL has been transformed successfully, the result will be run through the Rewrite rules again, to be transformed again. This continues for a single URL, as many times as necessary, or until the IterationLimit is exceeded, whichever comes first.

In short, the iteration happens if the output of a matched rule matches another rule.   You should not take the output from testdriver and run them through the testdriver again.  That won't reproduce what happens in IIS with the ISAPI. Just run URLs through the testdriver, and those URLs are subject to the same iteration rules as when IIRF is used in IIS.  

The most obvious way to see the URLs that get rewritten more than once is to examine the logfile.   (In the case of testdriver.exe, these log messages are displayed on the console)  The IterationLimit serves as a failsafe for this iteration.  As described in the readme file, the default level is 8.  So you will never get IIRF iterating more than 8 times on a single URL, and that is well below the threshold that will cause a stack overflow.

The PCRE loop is a completely different phenomenon, though it is similar in principle.   It has to do with the way patterns are matched against incoming text in the engine.   If you check the PCRE man page that I cited above, and look for "infinite loop", you'll see the explanation.  As far as I know there is no way to limit the PCRE iteration limit. 

It is clear from the stack overflow message that you described on stackoverflow.com the overflow is happening within pcre_exec().  I believe this has nothing to do with IIRF iterating repeatedly over URLs.  

Now, there are other possibilities for loops.  For example, suppose that you create a RedirectRule.  The output of the redirection gets sent back to the browser.  The browser then submits another (new) HTTP request.  Suppsoe that new HTTP request matches the input of the same RedirectRule.  (There could also be some intervening RewriteRule's in there).  The IIRF then Redirects the request to the URL, again.  The browser submits a new request, again.  Repeat endlessley. 

The situation I just described is a loop, but it is not done within the context of a single request, so it should not result in a stack overflow.  It might result in an IIS hang, but not an overflow, at least not as a primary result.

I say "should not" rather than "will not" because this is software we are talking about, and in a highly concurrent scenario, I don't know what might happen.   But as a primary result, a logical loop as I've described will not result in a stack overflow.

On the other hand, the problem you described on stackoverflow.com does not seem to be the same problem you described higher up in this thread.  But to figure it out, I now have to look at two different forums and sift through comments from 6 months back, and it's not a recipe for success.


Ok, so how do you troubleshoot IIRF crashes?  First thing I would focus on is reproducing it.   Narrowing down what led to the overflow will help.   It will likely be the most recent incoming URL recorded in the logfile (if you have logging turned on).  I also suggest that you start a new thread, and specifically describe the problem you are having.  I also suggest you confine the discussion to a single problem, and keep all the discussion in a single place.  Otherwise I just can't keep it all straight.  

You might think, come on, now, it's just a couple topics split over two forums.  But there are other threads I'm dealing with, and other forums, and it's impossible for me to manage it when it is scattered around. I wanna help but let's try to make it easier on ourselves.

 

 

Coordinator
Jul 5, 2009 at 11:01 PM

cfneedham,

thanks for your analysis and code fixes.  I included both of the ones you noted here, and built a new R6 release. It's available now.  I know you build your own releases, so you are probably not interested.  But thanks to you, for contributing.

Sorry for the silence on my part.  Lots of other things to keep me busy this year.

 

Jul 6, 2009 at 10:21 PM

Cheeso,

I apologize for the inconvenience of having a long thread and posting on multiple forums. Let me briefly explain how it led to this.

This thread IS ALL RELATED to the same problem. I have been getting the same Event Log errors on IIRF for many months now (app pool fatal communication error). Along the way, I have found that there are multiple causes for this error. First, it was a URL length issue, where certain types of URL attacks and extremely long URLs were causing IIRF to crash.  Beyond that fix, I am still receiving the same errors, but with less frequency. So the search for a fix continues. It seemed logical to continue updating one thread instead of having to reference back to old threads on several new ones.

And then there is the post about my stack overflow on StackOverflow.com. I went to S.O. searching for help because I was not getting help here. For many months I have been trying to reach you for assistance on this issue and finally went elsewhere to see if I could find some guidance. But then, to my surprise, you showed up posting there.

Where I am at right now is still trying to go through my rule set to ID the problematic URL which is causing this loop.  Hopefully I will be at a resolution very soon, as I think I have all the information I need now.

Once again, sorry for the inconvenience. I would not have gone to StackOverflow.com to post my question if I had gotten some direction earlier.

Coordinator
Jul 6, 2009 at 11:52 PM

Mmm, ok, well sorry for being unavailable for a while.

Just FYI, with this thread at 21 posts now, I'm having trouble digesting your current situation, and I don't know what to suggest.

Coordinator
Jul 7, 2009 at 12:57 PM

ps, are you using CondSubstringBackrefFlag *  ??  (check the readme for why)

Jul 7, 2009 at 11:33 PM

I am not using that CondSubstringBackrefFlag directive. I do see how it could cause problems, but I'm not using that.

I am still having a lot of problems with this, so I'm going to start a new thread and lay it all out clearly.

Coordinator
Jul 8, 2009 at 12:53 AM

Actually, I think using CondSubstringBackrefFlag might SOLVE some of your problems, particularly because the probs only occur on long URLs with URL-escaped sequences (%3C, etc).  This is the problem the directive was intended to address.

 

I'll look for the new thread.