wcf trying to set up tracing to debug, not writing to log file - wcf

here's my web.config, running a WCF service in an application on IIS7, but nothing is being written to the specified file. permission on the file has been granted for everyone.
<system.diagnostics>
<sources>
<source name="System.ServiceModel" switchValue="Information, ActivityTracing, error, warning, critical" propagateActivity="true">
<listeners>
<add name="traceListener"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="c:\log\tracestext.log" />
</listeners>
</source>
</sources>
</system.diagnostics>
I can add a service reference just fine.
I then try to call the service from a windows app and, after a few minutes, get an error on the machine running the windows app "Client is unable to finish the security negotiation within the configured timeout (00:00:00). The current negotiation leg is 1 (00:00:00)."
but absolutely nothing is written to the trace log file specified in config.
Is there something else I need to do to enable tracing? thanks for your help
EDIT: "sources" section now matches the section recommended here: http://msdn.microsoft.com/en-us/library/aa702726.aspx
I've added the "diagnostics . messagelogging" section to "system.servicemodel"
and the event viewer shows: "Message Logging has been turned on. Sensitive information may be logged in the clear, even if it was encrypted on the wire: for example, message bodies.
Process Name: w3wp
Process ID: 1784
"
but the log file is still empty

Yes - you've only just defined some .NET tracing source and listeners - but you haven't instructed WCF yet to actually do the tracing!
You also need:
<system.serviceModel>
<diagnostics>
<messageLogging
logMessagesAtTransportLevel="true" logMessagesAtServiceLevel="false"
logMalformedMessages="true" logEntireMessage="true"
maxSizeOfMessageToLog="65535000" maxMessagesToLog="500" />
</diagnostics>
</system.serviceModel>
These two sections of config combined should do it!
In order to get your messages written back to the log file right away, you might want to add a setting to your <system.diagnostics> section:
<system.diagnostics>
... everything you already have....
<trace autoflush="true" />
</system.diagnostics>

To write to the log file, make sure that identity running your web application has write access to the log directory.
You can find the identity in the IIS 7 management console. Select the application pool that your web application is using. Click on Advanced Settings... In the properties window, look for the identity field. It may say Network Service. This is the account that needs write permission to your log output folder.
If you already have a log file in this directory, try deleting it and letting the framework create it.
Hope this helps.

Make sure you have configured both the system.diagnostics and the
System.serviceModel/diagnostics sections configured.
Make sure you have them configured in the correct App.config/Web.config file. The thing to note is that multiple
config files may exist in a project, and the one used depends on the
Build Configuration.
Personally I had the very same symptom until I noticed that I put the sections under app.config (in my case, client side tracing), instead of app.DebugLocal.config. The later was used as my build configuration was set to DebugLocal.

Probably the issue is due to permission to write in the log directory specified in your config file.
If you are'nt sure wich is the user in the context, give write permission to all machine users.
Right click in log directory
Click in the "Security" tab
Click edit
On "Group Names or Users" section, select "Users MachineName\Users"
On "Permissions" section grant permission to write
It worked fine for me.

Related

asp.net core out-of-process fails to start correctly

I'm attempting to us the RunFromPackage App Setting for an Azure Web Site.
I'm using the following stack
asp.net core (out-of-process)
Targeting .Net Framework 4.7.2
and I can no longer get my web application to run correctly. when I hit the url all I get is
"The page cannot be displayed because an internal server error has occurred."
in the response.
I have launched my application using the Kudu powershell window with the command
".{applicationName}.exe"
and it start up fine. No errors or anything
Viewing the event viewer logs all I see is
APPLICATION_MANAGER::~APPLICATION_MANAGER | this=000001D1CD999A60 [TID 8872] [PID 8028]
When turning on the Failed Request Tracing Logs I see the following relevant information
URL_CACHE_ACCESS_START RequestURL="/favicon.ico" 15:37:30.729
URL_CACHE_ACCESS_END PhysicalPath="", URLInfoFromCache="false", URLInfoAddedToCache="true", ErrorCode="The operation completed successfully.
(0x0)" 15:37:30.729
GENERAL_GET_URL_METADATA PhysicalPath="", AccessPerms="545" 15:37:30.729
HANDLER_CHANGED OldHandlerName="", NewHandlerName="aspNetCore", NewHandlerModules="AspNetCoreModule", NewHandlerScriptProcessor="", NewHandlerType="" 15:37:30.729
MODULE_SET_RESPONSE_ERROR_STATUS
Warning ModuleName="IIS Web Core", Notification="BEGIN_REQUEST", HttpStatus="500", HttpReason="Internal Server Error", HttpSubStatus="0", ErrorCode="Access is denied.
(0x80070005)", ConfigExceptionInfo=""
I have tried to turn on the asp.net core module logging but I get no log files. I have also tried to turn on the stdoutlog but nothing is appearing to log.
Here is a copy of my web.config
<configuration>
<system.webServer>
<security>
<access sslFlags="SslNegotiateCert" />
</security>
<serverRuntime uploadReadAheadSize="30000000" />
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="%LAUNCHER_PATH%" stdoutLogEnabled="true" stdoutLogFile="\\?\%home%\LogFiles\stdout" hostingModel="OutOfProcess" arguments="%LAUNCHER_ARGS%">
<handlerSettings>
<handlerSetting name="debugFile" value="\\?\%home%\LogFiles\aspnetcore-debug.log" />
<handlerSetting name="debugLevel" value="FILE,TRACE" />
</handlerSettings>
</aspNetCore>
</system.webServer>
</configuration>
I'm not really sure what is going on. All I can gather is something is going wrong with the IIS Module. from the error message it appears that it cannot read or process my web.config ErrorCode="Access is denied."
Strangely enough I had a previous build of the application up and running. I have tried to isolate the changes that may have broke the site but I cant seem to find out what has cause this.
It appears that this was due to the fact I was trying to get only client authentication on one endpoint.
The following setting
<access sslFlags="SslNegotiateCert" />
in the web.config, and Require incoming Certificate in the App Settings caused my issue.
I then tried the feature of "Certificate exclusion paths" but having this and the web.config access node makes the web server very upset and causes the error message
"The page cannot be displayed because an internal server error has occurred."
I had to remove the node from my web.config file, leave the Required SSL, and set my Certificate Exclusion path and everything turned back online.

There was no endpoint listening at http://

I have a Windows forms app which uses WCF services. Our application sends messages using one of our WCF services to specific users running our client, so our callback “http:” string is dynamically constructed each time a message is sent to a user. It includes the server IP address and port (126.221.97.105:701) onto which the current user is logged, the user’s id (56281), and the client GUID (7392d27a-e4a0-42e2-89a3-adc332e28934). So, a typical callback “http:” string looks like this:
http://xxx.xxx.xx.xxx:701/CmesCns/CALLBACK/56281/7392d27a-e4a0-42e2-89a3-adc332e28934
We have an http namespace (http://+:701/) on our client and the group “Everyone” is tied to this namespace with all of the access permissions checked (GenericAll, GenericExecute, GenericRead, and GenericWrite). We use “http namespace” to create our namespaces.
Our application has been in production (on Windows Server 2003) for a few years and everything is working fine.
We have recently converted our application to run in the Windows 2008 server environment. The “Target Framework” in each of our projects is set to the “.NET Framework 4.0”. Our application works fine on my Windows 7 developer workstation. That is, I am able to receive messages from our WCF service, but when I place our application onto our Windows 2008 server and I attempt to run the application, I receive the following error message:
"There was no endpoint listening at http://xxx.xxx.xx.xxx:701/CmesCns/CALLBACK/56281/7392d27a-e4a0-42e2-89a3-adc332e28934
that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.”
The http namespace (http://+:701/) exists on my developer workstation and on my Windows 2008 server. The group “Everyone” is tied the namespace on my Windows 7 box and on my Windows 2008 server, and all of the access permissions are checked (GenericAll, GenericExecute, GenericRead, and GenericWrite).
We have been searching the web for an answer but have not discovered anything. Would anybody have any ideas on why this would work on our Windows 7 workstations, but not on our Windows 2008 servers?
Any help is greatly appreciated!
Kevin
When you host a WCF service in IIS you don't specify an absolute url in the address. You should use a relative url to the .svc file. The base url will be determined by the web site where it is hosted.
<service name="WebService.Receptor">
<endpoint
address="/WS.svc"
binding="wsHttpBinding"
contract="IMyContract"
/>
and on the client, depending on how your IIS is configured you should obviously specify the full address:
<client>
<endpoint
name="Receptor"
address="http://MyServer:8000/WS.svc"
binding="wsHttpBinding"
contract="IMyContract"
/>
This assumes that you have configured a site in IIS that listens on the 8000 port and that you have hosted your WCF application inside this site.
if it does not help please follow these links, hope it would be useful.
Stack overflow link
Multiple Endpoint
Typically, this error is because there is no endpoint on the server that matches what the client is requesting (the address, the service, or the authentication is different).
However, in my case, I had the exact same error, and it was not due to any of these things.
When I enabled the tracing on IIS and reviewed the svclog trace with SvcTraceViewer.exe (included in Visual Studio), the actual internal error was "Maximum request length exceeded."
My client was uploading an image via the service. And I guess the image was too big.
To enable tracing I added this to the configuration section:
<system.diagnostics>
<sources>
<source name="System.ServiceModel"
switchValue="All"
propagateActivity="true">
<listeners>
<add name="traceListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData= "c:\log\Traces.svclog" />
</listeners>
</source>
</sources>
To solve the error, I increased the message request length in the web config and the error went away.
To do this, in the system.websection in the web.config I added the line:
<httpRuntime maxRequestLength="32768" />
Then I added this section inside the configuration section
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="32000000" />
</requestFiltering>
</security>
</system.webServer>
So I recommend you enable tracing and then review the trace for the exact error.

How to use Fiddler to monitor WCF service

I have a WCF service that accepts a complex type and returns some data. I want to use Fiddler to see what the incoming requests to the service looks like. The client is .net console app which uses a Service reference proxy. Is this possible with Fiddler. I'm new to this tool and have only used it in the past to post data with the request builder.
You need to add this in your web.config
<system.net>
<defaultProxy>
<proxy bypassonlocal="False" usesystemdefault="True" proxyaddress="http://127.0.0.1:8888" />
</defaultProxy>
</system.net>
then Start Fiddler on the WEBSERVER machine.
Click Tools | Fiddler Options => Connections => adjust the port as 8888.(allow remote if you need that)
Ok, then from file menu, capture the traffic.
That's all, but don't forget to remove the web.config lines after closing the fiddler, because if you don't it will make an error.
Reference : http://fiddler2.com/documentation/Configure-Fiddler/Tasks/UseFiddlerAsReverseProxy
Fiddler listens to outbound requests rather than inbound requests so you're not going to be able to monitor all the requests coming in to your service by using Fiddler.
The best you're going to get with Fiddler is the ability to see all of the requests as they are generated by your Console App (assuming that the app generates web requests rather than using some other pipeline).
If you want a tool that is more powerful (but more difficult to use) that will allow you to monitor ALL incoming requests, you should check out WireShark.
Edit
I stand corrected. Thanks to Eric Law for posting the directions to configuring Fiddler to be a reverse proxy!
Just had this problem, what worked for me was to use localhost.fiddler:
<endpoint address="http://localhost.fiddler/test/test.svc"
binding="basicHttpBinding"
bindingConfiguration="customBinding"
contract="test"
name="customBinding"/>
Consolidating the caveats mentioned in comments/answers for several use cases.
Mostly, see http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/ConfigureDotNETApp
Start Fiddler before your app
In a console app, you might not need to specify the proxyaddress:
<proxy bypassonlocal="False" usesystemdefault="True" />
In a web application / something hosted in IIS, you need to add the proxyaddress:
<proxy bypassonlocal="False" usesystemdefault="True" proxyaddress="http://127.0.0.1:8888" />
When .NET makes a request (through a service client or HttpWebRequest, etc) it will always bypass the Fiddler proxy for URLs containing localhost, so you must use an alias like the machine name or make up something in your 'hosts' file (which is why something like localhost.fiddler or http://HOSTNAME works)
If you specify the proxyaddress, you must remove it from your config if Fiddler isn't on, or any requests your app makes will throw an exception like:
No connection could be made because the target machine actively refused it 127.0.0.1:8888
Don't forget to use config transformations to remove the proxy section in production
So simple, all you need is to change the address in the config client: instead of 'localhost' change to the machine name or IP
This is straightforward if you have control over the client that is sending the communications. All you need to do is set the HttpProxy on the client-side service class.
I did this, for example, to trace a web service client running on a smartphone. I set the proxy on that client-side connection to the IP/port of Fiddler, which was running on a PC on the network. The smartphone app then sent all of its outgoing communication to the web service, through Fiddler.
This worked perfectly.
If your client is a WCF client, then see this Q&A for how to set the proxy.
Even if you don't have the ability to modify the code of the client-side app, you may be able to set the proxy administratively, depending on the webservices stack your client uses.
Standard WCF Tracing/Diagnostics
If for some reason you are unable to get Fiddler to work, or would rather log the requests another way, another option is to use the standard WCF tracing functionality. This will produce a file that has a nice viewer.
Docs
See https://learn.microsoft.com/en-us/dotnet/framework/wcf/samples/tracing-and-message-logging
Configuration
Add the following to your config, make sure c:\logs exists, rebuild, and make requests:
<system.serviceModel>
<diagnostics>
<!-- Enable Message Logging here. -->
<!-- log all messages received or sent at the transport or service model levels -->
<messageLogging logEntireMessage="true"
maxMessagesToLog="300"
logMessagesAtServiceLevel="true"
logMalformedMessages="true"
logMessagesAtTransportLevel="true" />
</diagnostics>
</system.serviceModel>
<system.diagnostics>
<sources>
<source name="System.ServiceModel" switchValue="Information,ActivityTracing"
propagateActivity="true">
<listeners>
<add name="xml" />
</listeners>
</source>
<source name="System.ServiceModel.MessageLogging">
<listeners>
<add name="xml" />
</listeners>
</source>
</sources>
<sharedListeners>
<add initializeData="C:\logs\TracingAndLogging-client.svclog" type="System.Diagnostics.XmlWriterTraceListener"
name="xml" />
</sharedListeners>
<trace autoflush="true" />
</system.diagnostics>
I have used wire shark tool for monitoring service calls from silver light app in browser to service. try the link gives clear info
It enables you to monitor the whole request and response contents.
I just tried the first answer from Brad Rem and came to this setting in the web.config under BasicHttpBinding:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding bypassProxyOnLocal="False" useDefaultWebProxy="false" proxyAddress="http://127.0.0.1:8888" ...
...
</basicHttpBinding>
</bindings>
...
<system.serviceModel>
Hope this helps someone.
You can use the Free version of HTTP Debugger.
It is not a proxy and you needn't make any changes in web.config.
Also, it can show both; incoming and outgoing HTTP requests.
HTTP Debugger Free
Use fiddler a Reverse Proxy is the final solution for me.
First, configure fiddler as reverse proxy with REGDIT, like the doc said: https://docs.telerik.com/fiddler/configure-fiddler/tasks/usefiddlerasreverseproxy#configure-fiddler-as-reverse-proxy
1)Click Tools > Fiddler Options. Ensure Allow remote clients to connect is checked
2)Create a new DWORD named ReverseProxyForPort inside HKEY_CURRENT_USER\SOFTWARE\Microsoft\Fiddler2.
3)Set the DWORD to the local port where Fiddler will re-route inbound traffic.
4)Restart Fiddler.
Second, change the client to call service through proxy
for example , here is my client app.config:
<client>
<endpoint address="http://localhost:61236/WeatherForecastService.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IWeatherForecastService"
contract="ServiceReference1.IWeatherForecastService" name="BasicHttpBinding_IWeatherForecastService" />
</client>
change the client to use proxy endpoint address.
WeatherForecastServiceClient client = new WeatherForecastServiceClient("BasicHttpBinding_IWeatherForecastService", "http://localhost:8888/WeatherForecastService.svc");
var data = client.GetData(1000);
client.Close();
Change the localhost in the URL to localhost.fiddler, this small change worked for me.
Also if anyone testing the service from WCF Test Client don't forget to edit the URL in the config endpoint
Right click on the config file
Click Edit with Svc Config Editor
Click on Endpoints and edit the endpoint to localhost.fiddler
Check Start a new proxy while calling method

appsettings node in web.config WCF file gives an error when trying to debug

i have a WCf project,
when i add the following code to the configuration file (Web.config):
<configuration> <appsettings> <add key="Hello" value="5"/> </appsettings>....
i get this erro whentrying to debug:
"Unable to start debugging on the web server. The web server is not configured correctly. See help for common configuration errors. Running the web page outside of the debugger may provide further information."
when i drop the appsettings, the WCFTestClient opens.
how do i define constants in the web.config if not in that way ?
Solved this problem by putting the AppSettings node as the last node in the section and it works!
<appSettings><add key="hello" value="Monday" /></appSettings></configuration>
funny......
I think it the case problem. the Application settings section is defined as
<appSettings>..</appSettings>
I hope you have define the service settings in your web.config
<system.serviceModel>
<services>..</services>
<bindings>..</bindings>
<behaviors>...</behaviors>
</system.serviceModel>

WCF logging messages

I have a WCF service (hosted by IIS webpage) that is working but I want to write more info out to a log file.
I inherited code and it had some simple logging to a file. That worked on the original developers machine but I don't get anything written out. Note it reads the log file path from the config which I assume was the web config but just in case I hard coded the location for now "c:\temp\logfile.log".
I gave full permissions to temp to ASPNET and then USERS thinking it was a permissions issues.
Also I noticed there was Tracing and Message logging built into WCF. Tried that but not sure if I'm doing it correctly.
Any ideas about the simple file writing?
Should I be doing the built in logging and if so any simple examples?
Thanks!
To configure Logging:
Configure Logging
1. In the Configuration Editor, select the Diagnostics node.
2. In the right pane, click Enable MessageLogging.
This will create ServiceModelMessageLoggingListener and
System.ServiceModel.MessageLogging nodes under the Listeners and Sources
folders, respectively.
3. In the left pane, select MessageLogging under the Diagnostics node.
4. Set the LogMessagesAtServiceLevel attribute to True by choosing this option
from the drop-down list.
5. In the left pane, select ServiceModelMessageLoggingListener under the
Listeners node.
Note the default value of the InitData attribute, which is set to
c:\inetpub\wwwroot\WCFService\web_messages.svclog, the location where the
message will be logged.
via WCF Security Guidance.
Use the following in <system.serviceModel>
<diagnostics>
<messageLogging
logEntireMessage="true"
logMalformedMessages="false"
logMessagesAtServiceLevel="true"
logMessagesAtTransportLevel="false"
maxMessagesToLog="3000"
maxSizeOfMessageToLog="2000"/>
</diagnostics>
and use the following in <configuration>
<system.diagnostics>
<sources>
<source name ="System.ServiceModel" switchValue="Information, ActivityTracing">
<listeners>
<add name="xml" />
</listeners>
</source>
<source name ="System.ServiceModel.MessageLogging"
switchValue="Verbose, ActivityTracing">
<listeners>
<add name="xml" />
</listeners>
</source>
<source name ="System.Runtime.Serialization" switchValue="Verbose">
<listeners>
<add name="xml" />
</listeners>
</source>
</sources>
<sharedListeners>
<add name="xml" type="System.Diagnostics.XmlWriterTraceListener"
traceOutputOptions="LogicalOperationStack"
initializeData="C:\logs\RestAPISvcLog\Traces.svclog" />
</sharedListeners>
<trace autoflush="true" />
</system.diagnostics>
This will create log file and you can view directly that with svctracelog viewer (which comes with VS).
For more info refer this -- http://msdn.microsoft.com/en-us/library/ms730064(v=vs.110).aspx
Use the EventViewer logging instead, but you will have to make sure your installer can create the appropriate EventViewer source.
Maybe you should use that Configuration Editor-Tool "SvcConfigEditor.exe" (see description on MSDN). This allows to configure WCF-logging in a quiet easy and structured way.
The log files can then be analysed with the Service Trace Viewer-Tool "SvcTraceViewer.exe" (see on MSDN).
Both tools are bundled with Visual Studio an can be downloaded from Microsoft.
To write to the log file, make sure that the identity running your web application has write access to the log directory.
IIS7:
You can find the identity in the IIS management console. Select the application pool that your web application is using. Click on Advanced Settings. In the properties window, look for the identity field. It may say Network Service. This is the account that needs write permission to your log output folder.
IIS6:
Same as IIS7 except right click on the app pool and select properties. The properties window of IIS6 will have an Identity tab.
If you already have a log file in this directory, try deleting it and letting the framework create it.
Hope this helps.