Sladescross's Blog

Blogging about Sharepoint related stuff

PeoplePicker and LDAP Debugging March 12, 2014

Filed under: Debugging,LDAP,Limit,People Picker — sladescross @ 4:09 pm

From Wireshark the baked in LDAP from People Picker search.

Filter: (|(&(&(&(objectCategory=person)(objectClass=user))(!(userAccountControl:1.2.840.113556.1.4.803:=2)))(|(|(|(|(|(|(|(name=evans*)(displayName=evans*))(cn=evans*))(mail=evans*))(sn=evans*))(SamAccountName=evans*))(proxyAddresses=SMTP:

AttributeDescription: objectSID
AttributeDescription: mail
AttributeDescription: mobile
AttributeDescription: displayName
AttributeDescription: title
AttributeDescription: department
AttributeDescription: proxyAddresses
AttributeDescription: cn
AttributeDescription: samAccountName
AttributeDescription: groupType
AttributeDescription: userAccountControl
AttributeDescription: distinguishedName


Logs For Debugging January 1, 2014

Filed under: Debugging,Error Codes,Failed Request,HTTPERR.SYS,Logs,Troubleshooting — sladescross @ 8:54 pm

Failed Request Errors.

Application Event log

Application EventLog and look for Warning events from the ASP.NET 4.0.30319.0 or applicable version:

HTTPERR.SYS error codes.


SSIS Debugging and Error Handling December 15, 2013

Filed under: Debugging,Error Handling,Restarts,SSIS,Transactions — sladescross @ 11:52 pm


Fiddler Debug Outside of ASP.NET November 24, 2013

In a WinForms or Console application using the default proxy settings works just fine and Fiddler as well as other Http proxies like Charles automatically pick up the .NET Web Service/Http requests as they run through the Windows HTTP pipeline.


Fiddler or Charles no longer work directly on Web Service or straight HTTP calls using WebRequest/WebClient and if you’re expecting to debug a Web Service/Http request you get Nada in these Http debuggers.

explicitly specify the proxy settings in web.config:

    <proxy  proxyaddress="" />      

 You specify the proxy IP address and port as an Http Uri. These settings above are set for the default settings that Fiddler uses since both ASP.NET and Web Services Clients and Http Clients all access the settings from the configuration.

Applying these settings will make HttpWebRequest, WebClient and WCF or Web Service requests (as long as they’re using default ports) pick up the outbound requests and display Http request information.

If you run Https requests through these types of proxies you’ll need to add the specific certificates that Fiddler and Charles install to your personal trusted certificate store. If you don’t do this the requests will fail to invalid certificate errors.






Debugging ASP.NET Pages November 18, 2013

Filed under: ASP.NET,Debug,Debugging,Trace — sladescross @ 10:26 pm

Trace forwarding

ASP.NET 2.0 introduced new attribute to Web.config <trace> element that allows you to route messages emitted by ASP.NET tracing to System.Diagnostics.Trace:writeToDiagnosticsTrace.

< trace enabled =”true” requestLimit =”20″ writeToDiagnosticsTrace =”true ” pageOutput =”true”/>

When you set writeToDiagnosticsTrace to true, all calls to System.Web.UI.Page.Trace.Write(the ASP.NET TraceContent)  also go to System.Diagnostics.Trace.Write, enabling you to use all the standard TraceListeners.  The simple writeToDiagnosticsTrace setting connects the ASP.NET tracing functionality with the rest of the base class library.

New Trace Listeners in ASP.NET 2.0

The new ASP.NET 2.0 WebPageTraceListener derives from System.Diagnostics.TraceListener  and automatically forwards tracing information from any component calls to System.Diagnostics.Trace.Write.  This enables you to write your components using the most generic trace provider and to see its tracing output in the context of your ASP.NET application.

The WebPageTraceListener is added to the web.config as shown below.

< system.diagnostics>     <trace autoflush =”false” indentsize =”4″>       <listeners>         <add name=”webListeners”              type=”System.Web.WebPageTraceListener,  System.Web” />          </listeners>     </trace>


This walkthrough illustrated how to work with ASP.NET and System.Diagnostics tracing features to route all trace messages a single output. You might want to experiment more with trace listeners and output and ASP.NET instrumentation features. For example, you might want to do the following:
There are several ways to find errors in an ASP.NET Web page. This includes using the debugger and tracing. Tracing displays messages about the actions that occur during page processing, and can include information that you choose to display. Tracing also gives you information about the data that is being exchanged by the server and browser. The data exchange includes control details, server variables, user name, cookies, and so on. This walkthrough illustrates how to use tracing.

Visual Studio provides you with tools to help track down errors in your ASP.NET Web pages. In this walkthrough, you will work with the debugger, which allows you to step through the page’s code line by line and examine the values of variables.

In the walkthrough, you will create a Web page that contains a simple calculator that squares a number. After creating the page (which will include a deliberate error), you will use the debugger to examine the page as it is running.

The Visual Studio debugger has the ability to attach to a process that is running outside of Visual Studio. You can use this attach capability to do the following:

  • Debug an application that was not created in Visual Studio.
  • Debug multiple processes simultaneously. You can also debug multiple processes by starting multiple projects within a single solution.
  • Debug a process running on a remote computer.
  • Debug a DLL that runs in a separate process that cannot easily be started from Visual Studio, for example, a service or an ISAPI DLL running with Internet Information Services.
  • Start the debugger automatically when a process crashes while running outside of Visual Studio. This is Just-In-Time debugging.

You can control whether tracing is enabled or disabled for individual pages. If tracing is enabled, when the page is requested, ASP.NET appends to the page a series of tables containing execution details about the page request. Tracing is disabled by default.

Instead of enabling tracing for individual pages, you can enable it for your entire application. In that case, every page in your application displays trace information. Application tracing is useful when you are developing an application because you can easily enable it and disable it without editing individual pages. When your application is complete, you can turn off tracing for all pages at once.

When you enable tracing for an application, ASP.NET collects trace information for each request to the application, up to the maximum number of requests you specify. The default number of requests is 10. You can view trace information with the trace viewer.

By default, when the trace viewer reaches its request limit, the application stops storing trace requests. However, you can configure application-level tracing to always store the most recent tracing data, discarding the oldest data when the maximum number of requests is reached. For more information, see Application-Level Tracing Overview.

If you have enabled tracing for your application, when any page is requested, the page gathers trace information and executes any trace statements that it contains. You can view the trace output in the trace viewer. The trace viewer enables you to choose a specific request from the pages that have been requested from your application.

When you enable tracing for an application, you can display trace output in any page in the application by setting the pageOutput attribute of the trace element to true in the Web.config file.

To view trace details for a specific request

Navigate to Trace.axd in the root of your application.

For example, if the URL for your application is http://localhost/SampleApplication, navigate to http://localhost/SampleApplication/trace.axd to view the trace information for that application.

Select the View Details link for the request that you want to investigate.

To enable tracing for the page

  1. Open the FirstWebPage.aspx page and switch to Design view.
  2. In Properties, in the list, click DOCUMENT.This displays properties for the page.
  3. Set Trace to true.The trace setting is actually made as part of the @ Page directive. You can see this by switching to Source view and looking at the first line in the page. The @ Page directive will look similar to the following:
    <%@ Page language="C#"      Trace="true" %>

To view tracing output in a separate browser window

Press CTRL+F5 to run the page.

Notice that the page no longer displays trace output. The page looks the way a user would see it.

In the box, enter a name, and then click Submit to confirm that the page works correctly.

Open a new browser window.

In the browser, in the Address box, type the URL of your site, substituting trace.axd for the name of the page that you are working with.

For example, if the URL for the page is the following:






ASP.NET Page Life Cycle Ajax and Controls

When an ASP.NET page runs, the page goes through a life cycle in which it performs a series of processing steps. These include initialization, instantiating controls, restoring and maintaining state, running event handler code, and rendering. It is important for you to understand the page life cycle so that you can write code at the appropriate life-cycle stage for the effect you intend.

If you develop custom controls, you must be familiar with the page life cycle in order to correctly initialize controls, populate control properties with view-state data, and run control behavior code. The life cycle of a control is based on the page life cycle, and the page raises many of the events that you need to handle in a custom control.

Partial-page rendering removes the need for the whole page to be refreshed as the result of a postback. Instead, only individual regions of the page that have changed are updated. As a result, users do not see the whole page reload with every postback, which makes user interaction with the Web page more seamless. ASP.NET enables you to add partial-page rendering to new or existing ASP.NET Web pages without writing client script.

Debugging and tracing AJAX applications.

Configuring Internet Explorer for Debugging

By default, Internet Explorer ignores problems that it encounters in JavaScript. You can enable debugging by using the following procedure.

To enable debugging in Internet Explorer

  1. In the Tools menu, click Internet Options.
  2. In the Advanced tab, clear the Disable Script Debugging (Internet Explorer) check box and the Disable Script Debugging (Other) check box.
  3. Select the Display a notification about every script error check box.
  4. To turn off “friendly” error messages, clear the Show friendly HTTP error messages check box.If “friendly” error message are enabled and if an HTTP 500 error response from the server is less than 513 bytes long, Internet Explorer masks the content. In place of the error information, Internet Explorer displays a message that is meant for end users, not developers.

Attaching the Visual Studio Debugger to Internet Explorer

To debug client script, you must attach a debugger to Internet Explorer. In Visual Studio, if you start your application for debugging (by pressing F5 or using the Start Debugging command in the Debug menu), the debugger is attached automatically.

You can also attach the Visual Studio debugger to Internet Explorer when the application is already running. To do so, in the Debug menu, click Attach to Process…. In the Attach to Process dialog box, select the instance of Internet Explorer (iexplore.exe) that you want to attach the debugger to.

If Internet Explorer is configured for debugging, the Type column for the relevant instance of Internet Explorer displays Script, x86. If you see only x86 in the Type column, make sure that Internet Explorer is configured for debugging.

If Internet Explorer encounters a script error and is configured for script debugging, but it is not currently attached to a debugger, the browser prompts you to select a debugger. You can either continue without debugging or attach a debugger and step through the code.

The following list describes typical scenarios in which you are likely to develop your own controls and provides links to other topics for further information.

  • You have created an ASP.NET page that provides a user interface that you want to reuse in another application. You want to create a server control that encapsulates the user interface (UI) but do not want to write additional code. ASP.NET allows you to save your page as a user control without writing a single additional line of code. For details, see Web Forms User Controls.
  • You want to develop a compiled control that combines the functionality of two or more existing controls. For example, you need a control that encapsulates a button and a text box. You can do this using control composition, as described in Developing a Composite Control.
  • An existing ASP.NET server control almost meets your requirements but lacks some required features. You can customize an existing control by deriving from it and overriding its properties, methods, or events.
  • None of the existing ASP.NET server controls (or their combinations) meet your requirements. In that case, you can create a custom control by deriving from one of the base control classes. These classes provide all the plumbing needed by an ASP.NET server control, thus allowing you to focus on programming the features you need. To get started, see Developing Custom Controls: Key Concepts and Developing a Simple ASP.NET Server Control.

Many custom controls involve a combination of scenarios, where you combine existing ASP.NET server controls with custom controls that you have designed.

Note   The authoring paradigm outlined in the first bullet (user controls) is very different from that for the other scenarios. User controls are written using the same programming model as ASP.NET pages, and they are ideal for rapid control development. The other scenarios involve object-oriented programming in languages that target the common language runtime, such as Visual Basic .NET and C#. A user control is saved as an .ascx page, which is a text file, while the other scenarios create controls that are compiled and persisted in assemblies. For a summary of differences, see Composite Control vs. User Control.



IIS7 Debugging Using Events November 17, 2013

Filed under: Application Trace,Debugging,Event Tracing,HTTP.SYS,IIS7 — sladescross @ 8:16 pm



Dynamic Pipeline Mappings Debugging

WebResource.axd and ScriptResource.axd are Http Handlers used by ASP.NET and Ajax to add client-side scripting (usually javascript) to the outgoing web page for example to have client-side input validation, set the focus on a specific control (as in this example) etc… Note that if you search your disk for .axd files, you’ll not find them; they are created on the fly in memory and executed from there.

Another possibility is that the application mappings are not configured correctly (try with “aspnet_regiis –i”) or for some reason for the extension .axd the flag “Verify that file exists” flag has been set: if it is, remove it.

Pay attention to the last entry:


What is important here is the “Flags” part: “4” means “The server attempts to access the PATH_INFO portion of the URL, as a file, before starting the scripting engine. If the file can’t be opened, or doesn’t exist, an error is returned to the client”.

Here we are again… Check and clear the flag “Verify that file exists” for your wildcard application mapping. The point is that a wildcard ISAPI extension intercepts all requests and is executed as the first step for every of them; since WebResource.axd does not exist as a file on disk, IIS will not find it, will return a 404 error and will abort the request without passing it to aspnet_isapi.dll for further handling.


PowerShell 4 and Debugging and Remote Session

Filed under: Debugging,Powershell,PowerShell Debugging,Remote Session,Session — sladescross @ 4:36 pm

Example 2:  Create a new remote session and enter into an interactive session

PS C:\> Enter-PSSession –ComputerName localhost

[localhost]: PS C:\>

There is one significant difference between local script and remote script debugging. When debug and output data are stopped in the debugger during remote script debugging, the data arrives at the client through separate and unsynchronized streams. Because we didn’t want the output data to overwrite the prompt or other debugging information, Windows PowerShell suppresses script output data while the debugger is in Stop mode. The downside is that some script output might arrive later than expected.



PowerShell Debugging October 1, 2013

Filed under: Debugging,Powershell,PowerShell Debugging,Strict — sladescross @ 3:15 pm

Set-StrictMode -Version 2



Get every new post delivered to your Inbox.

Join 63 other followers