Last post Jun 19, 2007 06:17 PM by CarlFisher
Jun 14, 2007 03:27 PM|CarlFisher|LINK
I've got an ASP.NET v2.0 app that I instrumented with tracing information to debug an intermittent slow-loading problem. The log file and the trace information are being output correctly on my local box and the dev server, but the log file is not being
created on our test server.
I am using VS.NET's Publish Web Site feature to push the site up to both the Dev and Test boxes, using File System access via mapped drives.
My machine is Windows XP SP2, both the Dev and Test machines are Windows Server 2003 (Build 5.2). I have given the ASPNET user full control over the log file destination dir, which is also the application's root (e.g. wwwroot/myApp).
Here is a typical line from my codebehind:
System.Diagnostics.Trace.WriteLine(Microsoft.VisualBasic.DateAndTime.Now.ToString() & vbTab & "Calling SubscribeUser()", "SiteData")
Here is a snippet from my web.config:
<!-- I don't think I need this, but I'm trying anything at this point -->
<trace enabled="true" pageOutput="false" writeToDiagnosticsTrace="true" />
<!-- Uncomment the system.codedom and system.diagnostics sections below to enable tracing for
the application. Trace information is output to a file trace.log in the
application root folder.
type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.3500.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" warningLevel="1" />
type="Microsoft.VisualBasic.VBCodeProvider, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
type="System.Diagnostics.TextWriterTraceListener, System, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
Anyone have any ideas for me?
Thanks in advance!
Jun 18, 2007 03:58 AM|Rex Lin - MSFT|LINK
Please confirm the following things:
1. the servicename.exe.config is in the same folder with the servicename.exe
2. The trace.log file will be created in the \windows\system32 folder.
I tested the same scenerio, it works in my side.
I hope this helps. If you have any questions, please reply to this post.
Jun 18, 2007 09:40 AM|CarlFisher|LINK
Thanks for your reply. I'm afraid I don't understand it, though... [:S]
My app is a web application, so I'm not sure what servicename.exe.config I should be looking for. Nevertheless, I compared the search results from *.exe.config on my Dev box (where the tracing is being output correctly to wwwroot\MyApp\trace.log) to that
of the Test box (where it's not), and I get the exact same file list from both.
I also checked in \windows\system32 and my trace.log file isn't there, either. In fact I checked the entire box- no luck.
Thanks again, and I hope this update will help you spot my problem!
Jun 18, 2007 04:32 PM|CarlFisher|LINK
OK, I've found another clue- but still no answer...
I'll try to be as clear as possible
On both the Dev box (where tracing works) and the Test box (where it doesn't) my normal user domain account does not have login rights- I have to log in to those boxes using an administrator account. My web application uses Windows Integrated authentication,
and it is expecting to see my normal domain account's credentials- the administrator account's credentials are not valid for the app. Nevertheless, on a whim I tried hitting my app locally, and I got the expected authentication error. But, I noticed that
tracing did appear documenting the authentication failure!
In light of that discovery, I added my normal user account to the Remote Desktop Users group on the Test box. When I did that, tracing started working normally for me (hitting
http://TestServer/MyApp from my workstation)! Then, to confirm the notion, I removed my user account from the Remote Desktop Users group on the Test box, and tracing stopped being output.
I then went to the .NET\Framework\2.0x\CONFIG folders on both the Dev and Test machines and compared them, however I could find no differences in any of the files there.
So I think I found some useful clue here, but I don't know what it means! Does this ring a bell for anyone else?
Jun 18, 2007 11:43 PM|Rex Lin - MSFT|LINK
Have a try with this statement:
protected void Application_Start(Object sender, EventArgs e)
FileStream fs = new
StreamWriter sw = new StreamWriter(fs,System.Text.Encoding.UTF;
System.Diagnostics.TextWriterTraceListener txtListener = new
System.Diagnostics.Trace.AutoFlush = true;
I hope the above information will be helpful. If you have any issues or concerns, please let me know. It's my pleasure to be of assistance
Jun 19, 2007 06:17 PM|CarlFisher|LINK
Well, I didn't want to set up the tracing in code because I wanted to be able to turn the tracing on and off, as needed, on the production system in order to diagnose this intermittent problem. That, I thought, was one of the "big advantages" of the new
But I obviously needed to try something different, so I gave it a shot. Unfortunately, it didn't work either. No result whatsoever.
But, I did happen to notice an error in the Application event log:
Event code: 4011 Event message: An unhandled access exception has occurred. Event time: 6/19/2007 4:52:22 PM Event time (UTC): 6/19/2007 8:52:22 PM Event ID: 9a96af07186a4a1a8dcb16fb297679ac Event sequence: 2 Event occurrence: 1 Event detail code: 0 Application information: Application domain: /LM/W3SVC/1/Root/NorthStar-1-128267599415593715 Trust level: Full Application Virtual Path: /NorthStar Application Path: d:\inetpub\wwwroot\NorthStar\ Machine name: (removed) Process information: Process ID: 3304 Process name: w3wp.exe Account name: NT AUTHORITY\NETWORK SERVICE Request information: Request URL: http://(removed)/Northstar/default.aspx Request path: /Northstar/default.aspx User host address: (removed) User: Is authenticated: False Authentication Type: Thread account name: NT AUTHORITY\NETWORK SERVICE
So I checked the permissions for my site, and the NETWORK SERVICE user (in fact most users) had only "List Folder Contents" permission. So I gave it Read and Write permissions, and voila! Your traceLog.txt file appeared! [:)] But my web.config-based
tracing was still not showing- how come? On a hunch I gave the NETWORK user Read and Write permissions, and then my tracing started to appear too! [:D] [:D]
So I don't know if I found the real answer, but it does look like I found a workaround. A quick look around local servers showed that those very limited permissions for the NETWORK user were the norm, and if that's the IIS default nowadays then it seems
very strange that MS hasn't documented the fact that tracing won't work without upping those permissions. [*-)]
So, here's a quick summary (for anyone still reading):
Oh, and why did it work all along on my Dev box? Because somewhere along the line someone gave "Everyone" Full Control... [:$]
Thanks again for your help, Rex, and if anyone knows something more about what's
really happening, I'd love to know!