Step by step video on how to fix the SharePoint Workflow issue caused by .NET patch
This post is a continuation of this previous post. It is also an extension of KB4465015. The video assumes you read the previous post and/or KB. The page to the scripts mentioned in the video can be found here: https://gist.github.com/joerodgers/2302b394796c865818839d843bae2dad
SharePoint 2013/2016 Usage Reports fail to show the correct number of clicks from anonymous access
Symptom When using a Search Center with anonymous access, click statistics do not compute correctly for anonymous access but registers other user’s accesses properly. ULS logs will show entries like this: w3wp.exe SharePoint Foundation CSOM ajwqj Medium Request does not have SPBasePermissions.UseRemoteAPIs permission. Need to check it when each API is accessed Repro Steps Set
Leveraging the new Time Travel Trace API in Debugging tools to find when one or more SharePoint event happened
In my previous post, I showed a proof-of-concept script to list all occasions a process opened a file. JavaScript is easy to program and works for most cases, however in some occasions you need to access resources not available from JavaScript and only a full-fledged debugging extension will do. In this post I will show
Leveraging the new WinDbgX and Time-Travel-Trace –Script to list all access to files
WinDbg Preview a.k.a. WinDbgX aesthetically looks like a marriage between Visual Studio (VS) and WinDbg, however VS and WinDbg have not many things in common. For me, this is the good news. The bad news is that the support for managed code is as limited as WinDbg’s. You can download the preview here: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools
WinDBG Extension written completely in C#
A lot of good and competent people shy away from writing their own WinDbg extension because of the difficultyto prepare a native C++ DLL using the right APIs to interact with WinDbg. So this post is to get you started to writing your own extension using a proof-of-concept extension that can analyze manage dumps (as
Considerations for NetTcpBinding/NetNamedPipeBinding you may not be aware
NetTcpBinding is a strange beast and chances are you will encounter several problems in production you never experienced in development or staging phases. The information you will see here will be either fragmented or hidden in the fine print throughout MSDN documentation. Considerations about net.tcp binding Port Sharing Net.tcp services using shared port needs
Pure Native C++ consuming .NET classes without COM registration
One of the problems that many C++ native developers face when interacting with .NET is the inability to load a .NET COM Dll and use the COM classes without registering the DLL. I faced this problem when adapting the debugging NetExt from pure C++ to pure C++/.NET. As the idea of an extension is
Console Application to discover Effective Named Pipe Path of a WCF net.pipe Endpoint (Update for .NET 4.0+)
Named pipes created by WCF does not look like the endpoint at all. I discuss this at length here: Named Pipes in WCF are named but not by you (and how to find the actual windows object name) I wrote an console application to test it and I detailed this here: Console Application to
Windows 10 Preview does not allow you to change a network from public to private
*** UPDATE: This morning my Microsoft colleague Regan Murphy who is Technical Evangelist pointed me out that Windows 10 indeed can change from public to private via U (thank you Regan)I. I am posting his response below. I am keeping the original post as it may be useful for bulk changes and for System
First NetExt custom command added by the community – !wsocket
James Davis is a big shot in the debugging community and maintains a hard core blog of his experiences. Just soon after NetExt came back online he contacted me via the blog with some very particular questions, the kind of question only seasoned debuggers (and debug extension writers) know how to ask. He focused