For instance you can now write a dump at the time a specific first chance exception was raised using the exception name:

procdump –ma –e 1 –f “System.Exception” myprocess.exe

What’s also new and little hidden it the possibility to trace exception information in Process Monitor (ProcMon) traces.

In order to do this, you just need to attach procdump to the process you are interested in and tell it to observe all 1st chance exceptions:

procdump –e 1 –f “” myprocess.exe

When you now collect a procmon trace while exceptions occur, you will see them as Debug Output Profiling Operation Events coming out of the attached procmon instance:

Notice: You need to enable Profiling events to be displayed and make sure procmon,exe is not filtered as it was default until version 5.

This will work for managed and unmanaged exceptions as well.

Limitation: As you might now ProcMon can show you the call stack of the events. However, as the profiling event is generated from procmon itself and not the process that is actually monitored, these call stacks do not indicate where the exception was thrown.

DirectorySearcher.DirectorySynchronization Property is set and the DirectoryEntry is set to an Organisational Unit (OU) rather.

The following Example explains

   1:  using (DirectoryEntry deRoot = new DirectoryEntry("LDAP://OU=MyOU,DC=yourDomain,DC=com"))

   2:  {

   3:                  using (DirectorySearcher ret = new DirectorySearcher(deRoot))

   4:                  {                  

   5:                      ret.DirectorySynchronization = new DirectorySynchronization();

   6:                      ret.DirectorySynchronization.Option = DirectorySynchronizationOptions.IncrementalValues;

   7:   

   8:                      foreach (var result in ret.FindAll())

   9:                      {

  10:                          //do

  11:                      }

  12:                  }

  13:  }

While browsing the documentation and talking to an US colleague I realised that underneath the whole managed DirectoryServices infrastructure the DirSync Control is used for Directory Synchronization.

Following the Parameter description I found:

“The base of a DirSync search must be the root of a directory partition, which can be a domain partition, the configuration partition, or the schema partition.”

So the solution to the AccessDenied error is actuall pretty simple: Set the DirectoryEntry to the domain partition, the configuration partition, or the schema Partition when using it in conjunction with DirectorySynchronization and make use of the Filter Property when targeting at specific Sub segments of your Domain such as OUs.

See the correct example:

   1:  using (DirectoryEntry deRoot = new DirectoryEntry("LDAP://DC=yourDomain,DC=com"))

   2:  {

   3:                  using (DirectorySearcher ret = new DirectorySearcher(deRoot))

   4:                  {

   5:                      ret.Filter = "OU=MyOU";

   6:                      ret.DirectorySynchronization = new DirectorySynchronization();

   7:                      ret.DirectorySynchronization.Option = DirectorySynchronizationOptions.IncrementalValues;

   8:   

   9:                      foreach (var result in ret.FindAll())

  10:                      {

  11:                          //do

  12:                      }

  13:                  }

  14:  }

  15:   

I hope this works well for you, too. You are welcome to drop me a comment, once succeeded

This is because of an internal limitation trying to prevent you from exhaustive usage of synchronization primitives.

MSDN mentions it in the remark section:

https://msdn.microsoft.com/en-us/library/z6w25xa6(v=vs.90).aspx

“On some implementations, if more than 64 handles are passed, a NotSupportedException is thrown.”

My customer was under heavy time pressure with his project and just did not have enough time to refactor his threading approach which would have been the better solution actually.

So I suggested him to group all his waithandles in max 64 element arrays and joining them sequencially group by group.

The solution worked well thus I’m going to share it for you just in case …

   1:   

   2:  using System;

   3:  using System.Collections.Generic;

   4:  using System.Diagnostics;

   5:  using System.Linq;

   6:  using System.Text;

   7:  using System.Threading;

   8:   

   9:  namespace Hook

  10:  {

  11:      class Program

  12:      {

  13:          static void Main(string[] args)

  14:          {

  15:              Thread[] threads = new Thread[128];

  16:              WaitHandle[] whs = new WaitHandle[64];

  17:              WaitHandle[] whs2 = new WaitHandle[64];

  18:              for (int i = 0; i < 128; i++)

  19:              {

  20:                  WaitHandle wh = new AutoResetEvent(false);

  21:                  if (i >= 64)

  22:                      whs2[i - 64] = wh;

  23:                  else

  24:                      whs[i] = wh;

  25:   

  26:                  threads[i] = new Thread(DoNo);

  27:                  threads[i].Start(wh);

  28:              }

  29:   

  30:              WaitHandle.WaitAll(whs);

  31:              WaitHandle.WaitAll(whs2);

  32:          }

  33:   

  34:          private static void DoNo(object obj)

  35:          {

  36:              Thread.Sleep(1000);

  37:              AutoResetEvent wh = (AutoResetEvent)obj;

  38:              wh.Set();

  39:          }

  40:      }

  41:  }

Hope it works for you, too!

Sebastian

It turned out that the function call to kernel NtGdiSaveDC(hdc); Returns 0x0 after 999 iterations or at the 1000th call that is.

The public callstack subset looks like this:

…

gdiplus!MfEnumState::MfEnumState+0x85
gdiplus!WmfEnumState::WmfEnumState+0x25
gdiplus!MetafilePlayer::EnumerateWmfRecords+0x6e
gdiplus!GpGraphics::EnumEmf+0x282
gdiplus!GpMetafile::EnumerateForPlayback+0x5a7
gdiplus!GpGraphics::DrawImage+0x3f5
gdiplus!GpGraphics::DrawImage+0x51
gdiplus!GdipDrawImageRect+0x114

…

In the knowledge base I found that there is a Hotfix indeed to adress such issues in Win7 and Win Server 2008 R2.

https://support.microsoft.com/kb/2525949

It helped for my problem and I hope it will help you too!

Sebastian

There is a nice example how to do it in MSDN: https://msdn.microsoft.com/en-us/library/windows/desktop/aa363680(v=vs.85).aspx

When you are using the function ReportEvent the function might return the error  ERROR_INVALID_PARAMETER (0x57) if you are trying to report an event to an Event Source if the Source Name contains characters predefined in XML such as: “, &, ‘ <, >

Example Event Source: My<EventProvider>

The Problem with that is, that the underneath Event Logging Engine logs into XML files internally. Thus, using predefined XML characters causes subsequent validations to fail.

You can work around this problem by making use of the appropriate esacpe sequences:

Example of an Event Source containing XML escape sequences: My&lt;EventProvider&gt;

You need to apply the same logic for while reistering your custom Event Provider as shown below:

This is how it looks like when it succeeds:

Please let me know how it worked for you!

I chose to write some code that queries Bing Search Service for Images and displays results as
tiles.

I stumbled across some things that I want to share with you.

For details how to code against Bing Search please refer to the docs I will focus only on the steps necessary to
incorporate it in Metro Apps.

1) Download the latest Bing Azure Service Proxy and add the code file to your Metro App Project

2) With only default references the code does not compile you need to add references to the following Lib:

    C:\Program Files (x86)\Microsoft WCF Data Services\5.0\bin\Metro\Microsoft.Data.Services.Client.Metro.dll

3) You can now declare a bing search Service Proxy and create an instance consuming the Service Url and your unique ID:

BingSearchContainer bs = new BingSearchContainer(new Uri("https://api.datamarket.azure.com/Bing/Search/"));
_bsc.Credentials = new System.Net.NetworkCredential("YOUR_ID”,”YOUR_ID”);

4) Now, in order to run an actual query you need to create query object providing a query string and other options that
are unused in this example:

var webQ = _bsc.Image(search.Text, null, null, null, null, null);

5) You could now use the query object’s BeginExecute EndExecute Methods to asynchronously receive results using the
well-known Asynch Programming Pattern (APM).

6) But you could also make use of the new new async / await keywords. In order to do this you need to bridge between the
old APM the newer Task Parallel Librariy (TPL) to return a Task object which is required by the async keyword. The TaskFactory
helps you with that:

Task<int> bytesRead = Task<int>.Factory.FromAsync( stream.BeginRead, stream.EndRead, buffer, 0, buffer.Length, null);

7) I found it handy to use a generic extension method decorating the Bing Query with an await-compatible method that
returns the type you request for such as web results, images etc:

public static class QueryExtensions   
{        
     public static Task<IEnumerable<TResult>> QueryAsync<TResult>(this DataServiceQuery<TResult> query)
     {
            return Task<IEnumerable<TResult>>.Factory.FromAsync(query.BeginExecute, query.EndExecute, null);
     }
} 

8) Even though the implementation might look a little awkward, it’s application doesn’t and smart and simple. I assume
you are familiar with data-binding to Objects in the DefaultViewModel using Xaml:

DefaultViewModel["Items"] = await webQ.QueryAsync() ;

Hope it helps you easily integrating Bing Search Service into your Metro Apps – Happy coding!

PS: The Demo Project is attached to this post.

App1.zip

Everything that can be changed with TFS Explorer in the UI can also be modified using the API and command line tools.

TFSSECURITY.EXE is one of those allowing to batch script modifications to TFS’s security interface.

However, for some scenarios the tool application is pretty complicated as the required input parameters are hard to figure out due to  their low level.

A customer asked me how to grant or deny a set o users the privilege to manage build resources via shell script.

the syntax looks pretty straight forward:

   1: tfssecurity /a+ Namespace, Token and Action <user/group> Allow /collection:<collectionURI>

But how do you get all three parameters Namespace, Token and Action?

To get the namespace use TFSSecurity /a against the collection:

   1: tfssecurity /a /collection:<collectionURI>

Output [Namespaces]:

WorkItemQueryFolders
Registry
VersionControlItems
Identity
Job
Server
Collection
BuildAdministration
VersionControlPrivileges
Workspaces
Project
EventSubscription
CSS
TeamLabSecurity
Iteration
Build

Reading the token is the most tricky part and neither my EE colleague nor the WWW cam up with a better solution than running a SQL query against the confid DB:

   1: select distinct SecurityToken

   2: from Tfs_DefaultCollection..tbl_SecurityAccessControlEntry 

   3: where (SecurityToken not like '%/%' )and (SecurityToken not like '%$%')

Output [Tokens]:

BuildPrivileges
FrameworkGlobalSecurity
Global
NAMESPACE:

The action can be queried with tfssecurity once more (syntax):

   1: :  tfssecurity /a Namespace Token /collection:<collectionURI>

Example:

   1: tfssecurity /a BuildAdministration BuildPrivileges /collection:<collectionURI>

Output [Build Management Privileges]

ViewBuildResources
ManageBuildResources
UseBuildResources

Notice: This post focuses on build management privileges and does not cover all possible scenarios.

There is a pretty detailed forum answer in the MSDN forums which covers alternative ways to retrieve tokens for other tasks:

https://social.msdn.microsoft.com/Forums/en-US/tfsadmin/thread/f55d218f-03be-4825-ae1b-3988152a805d/

I’d love to read your feedback if this article helped you solve your problem!

The error did not appear when opening Excel right away and accessing a TFS query.

I was checking Process Monitor to see what was going on underneath using the comparison technique that I learned from Mark Russinovich.

It turned out that Excel 2007 was installed and it’s COM Classes are registered in HKCR\TypeLib\{00020813-0000-0000-C000-000000000046}\1.6.

In contrast when Team Explorer wanted call Excel through COM automation it used HKCR\TypeLib\{00020813-0000-0000-C000-000000000046}\1.7.

Obviously TFS was trying to talk to Excel 2010 instead which was not present.

So I rang the customer to discuss it further and it turned out that they installed Project 2010 to these boxes running Office 2007 that seemed to have added a newer automation class registry key for Excel though even though it was not even installed.

Anyway, deleting the key HKCR\TypeLib\{00020813-0000-0000-C000-000000000046}\1.7 solved the issue for the customer.

Project, Excel and Team Explorer work fine with that tiny little change.

My learnings: “When in doubt, run process monitor.”

The Hyper-V console’s status bar kept saying “Mouse not captured in remote desktop session“.

Fixing that issue is a little tricky and requires some keyboard acrobatics:

1) Uninstall the Virtual PC Tools… but how to reach the start button without a mouse and a Windows Key?

-> ALT+HOME is your friend and emulates the Windows Key!

-> Now just type “features” and press enter to open the list of installed programs

-> once the Programs and Features Window has opened press TAB until the actual list view has focus (boarders)

-> Press ENTER on the Virtual PC Tools and choose to uninstall

2) Install Hyper-V Tools now

-> In the Hyper-V Console Menu choose to insert the Integration Services Setup Disk

-> Now Autorun asks you whether to run the setup… just go for it.

3) The last and most tricky part (I didn’t know the option at all) is to make the guest OS use the changed hardware

-> Press ALT+HOME and navigate to “Run”

-> type msconfig and open the boot page

-> Enable “Detect HAL”

-> Close the dialogs and restart the system to activate your changes and your mouse should be working right away!

Shortly before I left, one of my colleagues helped me solving a case where a user wrote some VB Script code to access Active Directory Objects using the ADSI LDAP Provider.

That sounds actually more complicated than it is under the covers:

The Active Directory Service Interfaces (ADSI) Lightweight Directory Access Protocol (LDAP) provider implements OLE DB interfaces that allow you to use ActiveX Data Objects (ADO) to access objects in LDAP compliant directories.

Further ADSI details are explained in the KB.

One thing that was new to me was how to debug a VB Script using Visual Studio. The answer to this is also pretty simple: just run cscript.exe //d //x so that the default debugger gets attached when the script executes.

Further script debugging details are explained in this KB.

Anyway the actual customer problem however was a bit tricky so I think it is a good idea to share the solution just in case you run into the same issue yourself sometime.

Problem:

When accessing the value field of the ado recordset for “msExchRecipientTypeDetails” just like

 1: adoRecordSet.Fields("msExchRecipientTypeDetails").Value

The error “object doesn't support this property or method” is thrown even though the debugger watch windows indicates that there seems to be a value of an unknown type.

Cause:

The reason why this happens is because the actual type of the value that is returned is a 64bit integer as documented in

https://msdn.microsoft.com/en-us/library/microsoft.exchange.data.directory.sync.user.msexchrecipienttypedetails(v=exchg.140).aspx

The script engine seems to marshal such types as IADsLargeInteger Interface as documented in

https://msdn.microsoft.com/en-us/library/aa706037(VS.85).aspx

Solution:

This interface has a separate property for the 32bit low and the high part of 64bit value so that you can access it from VBS.

 1: adoRecordSet.Fields("msExchRecipientTypeDetails").Value.LowPart

Hope that helps you tackling your code issue. Feedback is appreciated…

Good Luck!