Re: win32traceutil - No output

[Mark Rees]

Just to confirm you enabled tracing by changing isapi_wsgi.py line 49 traceon = 1 and restarted IIS, prior to running win32traceutil?

Mark

On Tuesday, March 26, 2013 5:10:55 AM UTC+11, G. Richard Bellamy wrote:

BACKGROUND:
I'm trying to track down an issue where IIS 401s seem to be translating to client-side 404s.

The symptom is that inside the IIS logs, I only ever see 401s and 200s, never 404s. But clients are intermittently receiving "404 OK" errors.

I believe this is the result of the following code:

def _run_app(rootapp, apps, ecb):
    ecb_dict = ECBDictAdapter(ecb)
    path_info = interpretPathInfo(ecb_dict, apps.keys())
    loc = path_info.get('WSGI_SUBAPP')
    application = apps.get(loc, rootapp)
 
    # we have to pass path_info because otherwise the handler can't determine
    #  what the correct path is (because it doesn't know whether it's a
    #  subapp or not)
    handler = IsapiWsgiHandler(ecb, path_info)
    trace("Handler")
    try:
        if application is not None:
            handler.run(application)        
        else:
            handler.run(isapi_error) # RIGHT HERE IS A 404
    except ExtensionError:
        # error normally happens when client disconnects before
        # extension i/o completed
        pass
    except:
        # ToDo:Other exceptions should generate a nice page
        trace("Caught App Exception")
        pass
 
def isapi_error(environ, start_response):
    '''Send a nice error page to the client'''
    status = '404 OK'
    start_response(status, [('Content-type', 'text/plain')])
    return ['Page not found']

Specifically, the test for "application", when it is None, always outputs a 404. So anything wrong with "loc" or "path_info" could produce a 404. Now, how would I go about finding out what those values are?

PROBLEM:
When I try to view output (stdout, stderr, trace, whatever...), I get nothing when I run "python -m win32traceutil", regardless of privilege (e.g. I've run it as a normal user, and with elevated, "administrator" privilege). All the documentation make it look as easy as running that incantation, but I've found it to be completely opaque. It's not working for me on Windows 2008 R2, IIS 7.5 x64, and I am at a complete loss as to how I would troubleshoot a failure to get output from win32traceutil.

Hopefully this list still has lurkers on it that'll give me a pointer or two...

[Mark Hammond]

Actually, it might be necessary to run win32traceutil in an elevated
command-prompt *before* restarting IIS. The reason for this is that
win32traceutil first attempts to use a "global" event. If it can't find
a global event, it then attempts to *create* a global event, but this
requires elevated permissions. If this fails, it uses a "local" event,
which means only another win32traceutil run by the same user will be
able to see it.

By running win32traceutil elevated, it should first create the global
event, then set permissions on that event such that other non-elevated
processes can use it. This would then allow a new IIS instance to find
that global event, thus connecting the IIS process and the
win32traceutil process even though they are almost certainly being run
by different users.

Hope this helps,

Mark

On 26/03/2013 9:09 AM, Mark Rees wrote:
> Just to confirm you enabled tracing by changing isapi_wsgi.py line 49
> traceon = 1 and restarted IIS, prior to running win32traceutil?
>
> Mark
>
> On Tuesday, March 26, 2013 5:10:55 AM UTC+11, G. Richard Bellamy wrote:
>

> *BACKGROUND:*

> *PROBLEM:*

> When I try to view output (stdout, stderr, trace, whatever...), I
> get nothing when I run "python -m win32traceutil", regardless of
> privilege (e.g. I've run it as a normal user, and with elevated,
> "administrator" privilege). All the documentation make it look as
> easy as running that incantation, but I've found it to be completely
> opaque. It's not working for me on Windows 2008 R2, IIS 7.5 x64, and
> I am at a complete loss as to how I would troubleshoot a failure to
> get output from win32traceutil.
>
> Hopefully this list still has lurkers on it that'll give me a
> pointer or two...
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "isapi_wsgi-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to isapi_wsgi-de...@googlegroups.com.
> To post to this group, send email to isapi_w...@googlegroups.com.
> Visit this group at http://groups.google.com/group/isapi_wsgi-dev?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>