Getting WebDAV PUT To Work On IIS 7.0/Vista Ultimate - Inetserver

On Mar 17, 4:04 pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> Hi All,
>
> I am trying to set up Visutal Studio 2005/Visual Source Safe 2005 over
> HTTP from Vista Ultimate on client side to Vista Ultimate on server
> side with server running IIS 7.0 + newly-released WebDAV extensions.
>
> I have read numerous posts online, all generated within the past 3
> years about getting WebDA to work, and at this point, I would like to
> get the simplest success possible and go from there.
>
> The culprit appears to be the PUT verbe. I get the following error
> message during checking of a solution into a newly-created database.
>
> ---------------------------
> Visual SourceSafe Internet
> ---------------------------
> There was a failure uploading the URLhttp://terrastack.redirectme.net/SourceSafe/VssUpload_db1/4c7f8ea4-d6...{73765729-8996-42AC-BD99-D670633ED369}.
> Do you want to retry the operation?
> ---------------------------
> Yes   No
> ---------------------------
>
> The corresponding failure in the IIS log file is:
>
> 2008-03-17 21:09:33 192.168.1.50 PUT /SourceSafe/VssUpload_db1/
> e40b53f5-9c60-43a4-9423-8c31ae89068d/{E698EB8E-825F-46CA-A8D4-
> E68CD80606A2} - 80 Bunny 192.168.1.1 SourceSafe+Remote+MSSCCI+Client/
> 1.0 404 0 2 57
>
> As you can see, the IIS major code is 404, with minor code 0, Win32
> code of 2, which means "File Not Found." It appears to the the same
> symptoms experienced by hkasau on this link:
>
> http://forums.microsoft.com/MSDN/Sho...x=1&SiteID=1&P....
>
> I have spent more time on this "bug" than I have on any other software
> issue in the history of my career, a whopping 120+ hours.
>
> Note that, if you know how to get yours working with a virgin
> configuration, and you would not mind helping me do the same, I would
> be *OK* with that, as I have backups of everything, and would be *MORE
> THAN WILLING* to start over with virgin Vista Ultimate with virgin
> Visual Studio, etc, essentially a do-from-scratch everything.
>
> I need to see whether this works or not before deciding that my team
> should abandon Visual Source Safe, which would be a big change for us.
>
> TIA,
>
> -Le Chaud Lapin-



You don't have the same issue as hkasau.

URLScan is a tool meant for IIS5/IIS5.1. Why it was installed on IIS6,
who knows -- it's not installed by Microsoft by default, so if it was
on the system, it was put there by someone else in the organization.
Or possibly pushed down by Group Policy. Tons of bizarre IIS errors
are directly attributable to unintended Group Policy interactions.

URLScan is definitely not necessary for IIS7 nor installed (unless you
went and did it yourself), so it is unlikely your issue.

Security-related 404s are identified differently on IIS7, so I do not
believe you are seeing a security-related 404.

You can turn on Failed Request Tracing (it's an extra component that
you need to install) and have it track Failed Request Tracing for 404
errors. It will quickly identify which module returned the 404 and we
can go from there.

It almost seems like you have something configured on your server that
is converting PUT into GET and thus returning 404s (similar to the
Siteminder wildcard application mapping version of the problem).

As you can see, simple looking symptoms can have a ton of different
causes on IIS, and that is intentional. Web Server is an application
integration point so flexibility is important -- but with flexibility
comes an infinite number of ways for users and 3rd-Party Software to
misconfigure and shoot themselves.

The only solution, in my mind, is to learn how to troubleshoot.
http://blogs.msdn.com/david.wang/arc...eshooting.aspx

I may have written the guide for IIS6, but it applies pretty much to
IIS7 and every other piece of software (except IIS7 has Failed request
Tracing, which is the ultimate in IIS 7 troubleshooting -- for
example, one won't even need to provide any of your server's
configuration files to troubleshoot what went wrong -- of course, it
requires knowledge of IIS7 Integrated Pipeline internals, which is
only a few people at the moment).

If you would be so kind as to post the freb*.xml of the 404 --
hopefully we can make real progress so that you can stop wasting your
time spinning in circles.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

On Mar 17, 11:52 pm, David Wang <w3.4...@gmail.com> wrote:
> On Mar 17, 4:04 pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
>
>
>
>
>
> > Hi All,
>
> > I am trying to set up Visutal Studio 2005/Visual Source Safe 2005 over
> > HTTP from Vista Ultimate on client side to Vista Ultimate on server
> > side with server running IIS 7.0 + newly-released WebDAV extensions.
>
> > I have read numerous posts online, all generated within the past 3
> > years about getting WebDA to work, and at this point, I would like to
> > get the simplest success possible and go from there.
>
> > The culprit appears to be the PUT verbe. I get the following error
> > message during checking of a solution into a newly-created database.
>
> > ---------------------------
> > Visual SourceSafe Internet
> > ---------------------------
> > There was a failure uploading the URLhttp://terrastack.redirectme.net/SourceSafe/VssUpload_db1/4c7f8ea4-d6...{73765729-8996-42AC-BD99-D670633ED369}.
> > Do you want to retry the operation?
> > ---------------------------
> > Yes   No
> > ---------------------------
>
> > The corresponding failure in the IIS log file is:
>
> > 2008-03-17 21:09:33 192.168.1.50 PUT /SourceSafe/VssUpload_db1/
> > e40b53f5-9c60-43a4-9423-8c31ae89068d/{E698EB8E-825F-46CA-A8D4-
> > E68CD80606A2} - 80 Bunny 192.168.1.1 SourceSafe+Remote+MSSCCI+Client/
> > 1.0 404 0 2 57
>
> > As you can see, the IIS major code is 404, with minor code 0, Win32
> > code of 2, which means "File Not Found." It appears to the the same
> > symptoms experienced by hkasau on this link:
>
> >http://forums.microsoft.com/MSDN/Sho...x=1&SiteID=1&P....
>
> > I have spent more time on this "bug" than I have on any other software
> > issue in the history of my career, a whopping 120+ hours.
>
> > Note that, if you know how to get yours working with a virgin
> > configuration, and you would not mind helping me do the same, I would
> > be *OK* with that, as I have backups of everything, and would be *MORE
> > THAN WILLING* to start over with virgin Vista Ultimate with virgin
> > Visual Studio, etc, essentially a do-from-scratch everything.
>
> > I need to see whether this works or not before deciding that my team
> > should abandon Visual Source Safe, which would be a big change for us.
>
> > TIA,
>
> > -Le Chaud Lapin-
>
> You don't have the same issue as hkasau.
>
> URLScan is a tool meant for IIS5/IIS5.1. Why it was installed on IIS6,
> who knows -- it's not installed by Microsoft by default, so if it was
> on the system, it was put there by someone else in the organization.
> Or possibly pushed down by Group Policy. Tons of bizarre IIS errors
> are directly attributable to unintended Group Policy interactions.
>
> URLScan is definitely not necessary for IIS7 nor installed (unless you
> went and did it yourself), so it is unlikely your issue.
>
> Security-related 404s are identified differently on IIS7, so I do not
> believe you are seeing a security-related 404.
>
> You can turn on Failed Request Tracing (it's an extra component that
> you need to install) and have it track Failed Request Tracing for 404
> errors. It will quickly identify which module returned the 404 and we
> can go from there.
>
> It almost seems like you have something configured on your server that
> is converting PUT into GET and thus returning 404s (similar to the
> Siteminder wildcard application mapping version of the problem).
>
> As you can see, simple looking symptoms can have a ton of different
> causes on IIS, and that is intentional. Web Server is an application
> integration point so flexibility is important -- but with flexibility
> comes an infinite number of ways for users and 3rd-Party Software to
> misconfigure and shoot themselves.
>
> The only solution, in my mind, is to learn how to troubleshoot.http://blogs.msdn.com/david.wang/arc...TO_Basics_of_I...
>
> I may have written the guide for IIS6, but it applies pretty much to
> IIS7 and every other piece of software (except IIS7 has Failed request
> Tracing, which is the ultimate in IIS 7 troubleshooting -- for
> example, one won't even need to provide any of your server's
> configuration files to troubleshoot what went wrong -- of course, it
> requires knowledge of IIS7 Integrated Pipeline internals, which is
> only a few people at the moment).
>
> If you would be so kind as to post the freb*.xml of the 404 --
> hopefully we can make real progress so that you can stop wasting your
> time spinning in circles.
>
> //Davidhttp://w3-4u.blogspot.comhttp://blogs.msdn.com/David.Wang
> //- Hide quoted text -
>
> - Show quoted text -


I have spent but maybe 5-10 minutes thinking about your issue thus far
(spent much more time explaining to you what you were doing). Let's
see how long it takes me to figure out what you are observing --
please reproduce the issue with Failed Request Tracing enabled and
post the freb*.xml file.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

On Mar 18, 1:54 am, David Wang <w3.4...@gmail.com> wrote:
> On Mar 17, 11:52 pm, David Wang <w3.4...@gmail.com> wrote:
> I have spent but maybe 5-10 minutes thinking about your issue thus far
> (spent much more time explaining to you what you were doing). Let's
> see how long it takes me to figure out what you are observing --
> please reproduce the issue with Failed Request Tracing enabled and
> post the freb*.xml file.

My pleasure.

-Le Chaud Lapin-

This fr000001.xml, very slightly edited to remove private information:

<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type='text/xsl' href='freb.xsl'?>
<!-- saved from url=(0014)about:internet -->
<failedRequest url="http://HotBunny.xxxxxxxx.com:80/SourceSafe/
VssUpload_db1/d64e1526-e31d-4329-9dc1-2de171153f57/{BEB37BCD-F708-4251-
A24F-EA9D6446F7C7}"
siteId="1"
appPoolId="Classic .NET AppPool"
processId="4816"
verb="PUT"
remoteUserName="Lapin"
userName="Lapin"
tokenUserName="HotBunny\Lapin"
authenticationType="Basic"
activityId="{00000000-0000-0000-4601-0080000000FE}"
failureReason="STATUS_CODE"
statusCode="404"
triggerStatusCode="404"
timeTaken="62"
xmlns:freb="http://schemas.microsoft.com/win/2006/06/
iis/freb"
>
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="WWW Server" Guid="{3A2A4E84-4C21-4981-
AE10-3FDA0D9B0F83}"/>
<EventID>0</EventID>
<Version>1</Version>
<Level>0</Level>
<Opcode>1</Opcode>
<Keywords>0x0</Keywords>
<TimeCreated SystemTime="2008-03-18T18:37:58.700Z"/>
<Correlation ActivityID="{00000000-0000-0000-4601-0080000000FE}"/>
<Execution ProcessID="4816" ThreadID="3028"/>
<Computer>HotBunny</Computer>
</System>
<EventData>
<Data Name="ContextId">{00000000-0000-0000-4601-0080000000FE}</Data>
<Data Name="SiteId">1</Data>
<Data Name="AppPoolId">Classic .NET AppPool</Data>
<Data Name="ConnId">1610612919</Data>
<Data Name="RawConnId">0</Data>
<Data Name="RequestURL">http://HotBunny.xxxxxxxx.com:80/SourceSafe/
VssUpload_db1/d64e1526-e31d-4329-9dc1-2de171153f57/{BEB37BCD-F708-4251-
A24F-EA9D6446F7C7}</Data>
<Data Name="RequestVerb">PUT</Data>
</EventData>
<RenderingInfo Culture="en-US">
<Opcode>GENERAL_REQUEST_START</Opcode>
</RenderingInfo>
<ExtendedTracingInfo xmlns="http://schemas.microsoft.com/win/2004/08/
events/trace">
<EventGuid>{D42CF7EF-DE92-473E-8B6C-621EA663113A}</EventGuid>
</ExtendedTracingInfo>
</Event>
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="WWW Server" Guid="{3A2A4E84-4C21-4981-
AE10-3FDA0D9B0F83}"/>
<EventID>0</EventID>
<Version>1</Version>
<Level>0</Level>
<Opcode>33</Opcode>
<Keywords>0x0</Keywords>
<TimeCreated SystemTime="2008-03-18T18:37:58.762Z"/>
<Correlation ActivityID="{00000000-0000-0000-4601-0080000000FE}"/>
<Execution ProcessID="4816" ThreadID="3028"/>
<Computer>HotBunny</Computer>
</System>
<EventData>
<Data Name="ContextId">{00000000-0000-0000-4601-0080000000FE}</Data>
<Data Name="HttpStatus">404</Data>
<Data Name="HttpSubStatus">0</Data>
<Data Name="FileNameOrURL">404.htm</Data>
</EventData>
<RenderingInfo Culture="en-US">
<Opcode>GENERAL_SEND_CUSTOM_ERROR</Opcode>
</RenderingInfo>
<ExtendedTracingInfo xmlns="http://schemas.microsoft.com/win/2004/08/
events/trace">
<EventGuid>{D42CF7EF-DE92-473E-8B6C-621EA663113A}</EventGuid>
</ExtendedTracingInfo>
</Event>
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="WWW Server" Guid="{3A2A4E84-4C21-4981-
AE10-3FDA0D9B0F83}"/>
<EventID>0</EventID>
<Version>1</Version>
<Level>0</Level>
<Opcode>2</Opcode>
<Keywords>0x0</Keywords>
<TimeCreated SystemTime="2008-03-18T18:37:58.762Z"/>
<Correlation ActivityID="{00000000-0000-0000-4601-0080000000FE}"/>
<Execution ProcessID="4816" ThreadID="3028"/>
<Computer>HotBunny</Computer>
</System>
<EventData>
<Data Name="ContextId">{00000000-0000-0000-4601-0080000000FE}</Data>
<Data Name="BytesSent">1405</Data>
<Data Name="BytesReceived">867</Data>
<Data Name="HttpStatus">404</Data>
<Data Name="HttpSubStatus">0</Data>
</EventData>
<RenderingInfo Culture="en-US">
<Opcode>GENERAL_REQUEST_END</Opcode>
</RenderingInfo>
<ExtendedTracingInfo xmlns="http://schemas.microsoft.com/win/2004/08/
events/trace">
<EventGuid>{D42CF7EF-DE92-473E-8B6C-621EA663113A}</EventGuid>
</ExtendedTracingInfo>
</Event>
</failedRequest>

On Mar 18, 2:00 pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> On Mar 18, 1:54 am, David Wang <w3.4...@gmail.com> wrote:
>
> > On Mar 17, 11:52 pm, David Wang <w3.4...@gmail.com> wrote:
> > I have spent but maybe 5-10 minutes thinking about your issue thus far
> > (spent much more time explaining to you what you were doing). Let's
> > see how long it takes me to figure out what you are observing --
> > please reproduce the issue with Failed Request Tracing enabled and
> > post the freb*.xml file.
>
> My pleasure.

Hi David,

Also note that I have WinHTTP ready, so I can generate any other
request by hand if you like.

For example, I executed the following code:

wchar_t szBuffer[1024];
dwSize = sizeof(szBuffer);
::HttpQueryInfo(hRequest, HTTP_QUERY_ALLOW, &szBuffer, &dwSize,
NULL);

And got the following back:

szBuffer = 0x0012d47c "GET, HEAD, OPTIONS, TRACE, COPY, PROPFIND,
DELETE, MOVE, PROPPATCH, MKCOL"

The PUT verb is conspicuously absent.

-Le Chaud Lapin-

On Mar 18, 12:09 pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> On Mar 18, 2:00 pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
>
> > On Mar 18, 1:54 am, David Wang <w3.4...@gmail.com> wrote:
>
> > > On Mar 17, 11:52 pm, David Wang <w3.4...@gmail.com> wrote:
> > > I have spent but maybe 5-10 minutes thinking about your issue thus far
> > > (spent much more time explaining to you what you were doing). Let's
> > > see how long it takes me to figure out what you are observing --
> > > please reproduce the issue with Failed Request Tracing enabled and
> > > post the freb*.xml file.
>
> > My pleasure.
>
> Hi David,
>
> Also note that I have WinHTTP ready, so I can generate any other
> request by hand if you like.
>
> For example, I executed the following code:
>
>         wchar_t szBuffer[1024];
>         dwSize = sizeof(szBuffer);
>         ::HttpQueryInfo(hRequest, HTTP_QUERY_ALLOW, &szBuffer, &dwSize,
> NULL);
>
> And got the following back:
>
> szBuffer = 0x0012d47c "GET, HEAD, OPTIONS, TRACE, COPY, PROPFIND,
> DELETE, MOVE, PROPPATCH, MKCOL"
>
> The PUT verb is conspicuously absent.
>
> -Le Chaud Lapin-


We need to know what module and handler ultimately handled the PUT
request, and that's not in the edited Freb XML that you posted. Feel
free to email me the complete file -- there is no way I can make an
independent assessment if my data is filtered through your lense.

If you want to faithfully believe in the return value of the OPTIONS
request, go ahead... but I know why I'm not.

At this point, it doesn't look like the request is handled by a
handler that treated the PUT verb, and it handled it like a GET verb,
which would expectedly return a 404. Freb will identify the culprit,
at which point we move into either "why is the handler broken" or "why
is the request not being handled", and then quickly into "what's the
right configuration" or "what's the bug".


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

On Mar 18, 2:09 pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> On Mar 18, 2:00 pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
>
> > On Mar 18, 1:54 am, David Wang <w3.4...@gmail.com> wrote:
>
> > > On Mar 17, 11:52 pm, David Wang <w3.4...@gmail.com> wrote:
> > > I have spent but maybe 5-10 minutes thinking about your issue thus far
> > > (spent much more time explaining to you what you were doing). Let's
> > > see how long it takes me to figure out what you are observing --
> > > please reproduce the issue with Failed Request Tracing enabled and
> > > post the freb*.xml file.

Hi David,

I guess I should tell you that it has been several hours since your
last post in this thread, #6, that I have been trying to view it and
cannot. I am using IE7 with Google's web-based reader. Not sure why.
Refreshing does not help.

-Le Chaud Lapin-

On Mar 18, 1:54 am, David Wang <w3.4...@gmail.com> wrote:
> I have spent but maybe 5-10 minutes thinking about your issue thus far
> (spent much more time explaining to you what you were doing). Let's
> see how long it takes me to figure out what you are observing --
> please reproduce the issue with Failed Request Tracing enabled and
> post the freb*.xml file.

I thought I should reiterate that your last post, #6 in this thread,
is inaccessible, so I have no idea what your response was.

Thanks,

-Le Chaud Lapin-

On Mar 19, 9:53 pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> On Mar 18, 1:54 am, David Wang <w3.4...@gmail.com> wrote:
>
> > I have spent but maybe 5-10 minutes thinking about your issue thus far
> > (spent much more time explaining to you what you were doing). Let's
> > see how long it takes me to figure out what you are observing --
> > please reproduce the issue with Failed Request Tracing enabled and
> > post the freb*.xml file.
>
> I thought I should reiterate that your last post, #6 in this thread,
> is inaccessible, so I have no idea what your response was.
>
> Thanks,
>
> -Le Chaud Lapin-


Ditto. I'm also using IE7 with Google's news reader, which has
certainly flaked out on me several times in the past -- in this
particular instance, both the posts I made before and after responding
to yours exist. Maybe you can consider the news reader yet something
more that is plotting against you... ;-)

I had asked you to email the entire freb XML file to me (the gmail
address) because I need to see the modules and handlers involved on
the request. Besides, you want me to make an independent assessment,
not one that is filtered through your lense, right. :-)


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

On Mar 20, 3:38 am, David Wang <w3.4...@gmail.com> wrote:
> Ditto. I'm also using IE7 with Google's news reader, which has
> certainly flaked out on me several times in the past -- in this
> particular instance, both the posts I made before and after responding
> to yours exist. Maybe you can consider the news reader yet something
> more that is plotting against you... ;-)
>
> I had asked you to email the entire freb XML file to me (the gmail
> address) because I need to see the modules and handlers involved on
> the request. Besides, you want me to make an independent assessment,
> not one that is filtered through your lense, right. :-)

Right. Here's a repost of the .XML, if this is what you mean. The
message that I cannot see on Google is #6:

-Le Chaud Lapin-

This fr000001.xml, very slightly edited to remove private
information:

<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type='text/xsl' href='freb.xsl'?>
<!-- saved from url=(0014)about:internet -->
<failedRequest url="http://HotBunny.xxxxxxxx.com:80/SourceSafe/
VssUpload_db1/d64e1526-e31d-4329-9dc1-2de171153f57/{BEB37BCD-
F708-4251-
A24F-EA9D6446F7C7}"
siteId="1"
appPoolId="Classic .NET AppPool"
processId="4816"
verb="PUT"
remoteUserName="Lapin"
userName="Lapin"
tokenUserName="HotBunny\Lapin"
authenticationType="Basic"
activityId="{00000000-0000-0000-4601-0080000000FE}"
failureReason="STATUS_CODE"
statusCode="404"
triggerStatusCode="404"
timeTaken="62"
xmlns:freb="http://schemas.microsoft.com/win/2006/06/
iis/freb"
>
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="WWW Server" Guid="{3A2A4E84-4C21-4981-
AE10-3FDA0D9B0F83}"/>
<EventID>0</EventID>
<Version>1</Version>
<Level>0</Level>
<Opcode>1</Opcode>
<Keywords>0x0</Keywords>
<TimeCreated SystemTime="2008-03-18T18:37:58.700Z"/>
<Correlation ActivityID="{00000000-0000-0000-4601-0080000000FE}"/>
<Execution ProcessID="4816" ThreadID="3028"/>
<Computer>HotBunny</Computer>
</System>
<EventData>
<Data Name="ContextId">{00000000-0000-0000-4601-0080000000FE}</
Data>
<Data Name="SiteId">1</Data>
<Data Name="AppPoolId">Classic .NET AppPool</Data>
<Data Name="ConnId">1610612919</Data>
<Data Name="RawConnId">0</Data>
<Data Name="RequestURL">http://HotBunny.xxxxxxxx.com:80/SourceSafe/
VssUpload_db1/d64e1526-e31d-4329-9dc1-2de171153f57/{BEB37BCD-
F708-4251-
A24F-EA9D6446F7C7}</Data>
<Data Name="RequestVerb">PUT</Data>
</EventData>
<RenderingInfo Culture="en-US">
<Opcode>GENERAL_REQUEST_START</Opcode>
</RenderingInfo>
<ExtendedTracingInfo xmlns="http://schemas.microsoft.com/win/
2004/08/
events/trace">
<EventGuid>{D42CF7EF-DE92-473E-8B6C-621EA663113A}</EventGuid>
</ExtendedTracingInfo>
</Event>
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="WWW Server" Guid="{3A2A4E84-4C21-4981-
AE10-3FDA0D9B0F83}"/>
<EventID>0</EventID>
<Version>1</Version>
<Level>0</Level>
<Opcode>33</Opcode>
<Keywords>0x0</Keywords>
<TimeCreated SystemTime="2008-03-18T18:37:58.762Z"/>
<Correlation ActivityID="{00000000-0000-0000-4601-0080000000FE}"/>
<Execution ProcessID="4816" ThreadID="3028"/>
<Computer>HotBunny</Computer>
</System>
<EventData>
<Data Name="ContextId">{00000000-0000-0000-4601-0080000000FE}</
Data>
<Data Name="HttpStatus">404</Data>
<Data Name="HttpSubStatus">0</Data>
<Data Name="FileNameOrURL">404.htm</Data>
</EventData>
<RenderingInfo Culture="en-US">
<Opcode>GENERAL_SEND_CUSTOM_ERROR</Opcode>
</RenderingInfo>
<ExtendedTracingInfo xmlns="http://schemas.microsoft.com/win/
2004/08/
events/trace">
<EventGuid>{D42CF7EF-DE92-473E-8B6C-621EA663113A}</EventGuid>
</ExtendedTracingInfo>
</Event>
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="WWW Server" Guid="{3A2A4E84-4C21-4981-
AE10-3FDA0D9B0F83}"/>
<EventID>0</EventID>
<Version>1</Version>
<Level>0</Level>
<Opcode>2</Opcode>
<Keywords>0x0</Keywords>
<TimeCreated SystemTime="2008-03-18T18:37:58.762Z"/>
<Correlation ActivityID="{00000000-0000-0000-4601-0080000000FE}"/>
<Execution ProcessID="4816" ThreadID="3028"/>
<Computer>HotBunny</Computer>
</System>
<EventData>
<Data Name="ContextId">{00000000-0000-0000-4601-0080000000FE}</
Data>
<Data Name="BytesSent">1405</Data>
<Data Name="BytesReceived">867</Data>
<Data Name="HttpStatus">404</Data>
<Data Name="HttpSubStatus">0</Data>
</EventData>
<RenderingInfo Culture="en-US">
<Opcode>GENERAL_REQUEST_END</Opcode>
</RenderingInfo>
<ExtendedTracingInfo xmlns="http://schemas.microsoft.com/win/
2004/08/
events/trace">
<EventGuid>{D42CF7EF-DE92-473E-8B6C-621EA663113A}</EventGuid>
</ExtendedTracingInfo>
</Event>
</failedRequest>