Quantcast
Channel: Windows SDK Support Team Blog
Viewing all 126 articles
Browse latest View live

How to resolve a System.Security.Principal.IdentityNotMappedException?

$
0
0

The System.Security.Principal.IdenityNotMappedException seems to come up time to time and I thought I would write about what this exception means and how to resolve the issue.

The first thing to understand is that in Windows, User Accounts and Groups have a unique and immutable identifier known as a Security Identifier (SID).  (You can find more information on SIDs at http://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx) When working with User Accounts and Groups in Windows, you can work with them via their SID or by their name.

In Windows, a user is represented by an Access Token (You can find more information on Access Tokens at http://msdn.microsoft.com/en-us/library/windows/desktop/aa374909(v=vs.85).aspx) which can be associated with a process or to a thread (via impersonation).  The token contains the user’s SID and all the Groups the user is a member of.  The token contains the Group SIDs.  (The groups are NOT stored by their names)

There are Win32 APIs that allow an application to translate between the name and the SID. 

LookupAccountName() is used to translate from a Name to a SID

http://msdn.microsoft.com/en-us/library/windows/desktop/aa379159(v=vs.85).aspx

LookupAccountSid() is used to translate a SID to a Name

http://msdn.microsoft.com/en-us/library/windows/desktop/aa379166(v=vs.85).aspx

These Win32 APIs actually calls the LSA APIs.  (One difference with these APIs is that they do allow you to translate multiple names/SIDs versus just one.)

LsaLookupNames2()

http://msdn.microsoft.com/en-us/library/windows/desktop/ms721798(v=vs.85).aspx

LsaLookupSids()

http://msdn.microsoft.com/en-us/library/windows/desktop/ms721799(v=vs.85).aspx

When converting between a Name and a SID and vice versa, you can encounter an error if the translation can’t be done.  The common Win32 Error code that you will see is 1332 also known as ERROR_NONE_MAPPED which translates to “No mapping between account names and security IDs was done.”

At the LSA API level where status errors are returned, the error is:

STATUS_NONE_MAPPED or STATUS_SOME_NOT_MAPPED

In .NET, the error code is mapped as the following exception:

System.Security.Principal.IdentityNotMappedException

Why would the translation APIs fail?  Well, the API remarks provides some details on how the translation is done.  It uses a lookup order to translate (there is also a local cache as well)

In addition to looking up SIDs for local accounts, local domain accounts, and explicitly trusted domain accounts, LsaLookupSids can look up SIDs for any account in any domain in the Windows forest, including SIDs that appear only in the SIDhistory field of an account in the forest. The SIDhistory field stores the former SIDs of an account that has been moved from another domain. To perform these searches, the function queries the global catalog of the forest.

So a translation failure could happen if you have an issue with your Domain(s) or an issue with SID History.

So the first step in determining the issue is identifying which user or SID is the issue.  Once you have identified the User or SID, you can then review its relationship with the caller (who is this and what domain do they belong to and what domain does the system belong to where the caller is running)

Finally, a word of advice, internally most APIs are going to be working with SIDs so you can avoid the translation error and improve performance by always trying to work with SIDs.

You’ll notice that most classes in .NET such as IsInRole() allows you to specify a SID instead of the name (via the SecurityIdentifier class).  WindowsIdentity.Groups allows you access to the SID as well.


How to launch a process as a different user without storing their credentials?

$
0
0

You may run into a situation where you need to create a token to be used at a later time since you can’t keep the credentials around in your application.  The token representing the user is going to be used to launch a process.  In the past, this would be done by generating the token with LogonUser() and then launching the application with CreateProcessAsUser().  In order to launch an INTERACTIVE process, you need to modify the INTERACTIVE Window Station and Desktop (referred to as the INTERACTIVE desktop) to grant access to the user,   http://support.microsoft.com/kb/165194.  (The KB article was written by me).  The weakness in this technique is that you are responsible for the DACLs on the INTERACTIVE Window Station and Desktop.  Since this a SYSTEM named object, the SYSTEM (and other processes) may not be aware of the changes that you have made.   If the SYSTEM or another process makes a change to the DACLs and is unaware of your changes, your user will not have any more access to the INTERACTIVE desktop.

A better technique for granting access to the user is to use the technique used by CreateProcessWithLogonW().  CreateProcessWithLogonW() internally grants access to the user by obtaining the LOGON SID of the current INTERACTIVELY logged on user and adding this LOGON SID to the user specified in CreateProcessWithLogonW(). 

What you can do is launch a temporary process suspended.  CreateProcessWithLogonW() will go through the steps of creating the token with the appropriate permissions to the INTERACTIVE desktop.  You can then obtain this token via a call to OpenProcessToken().  You can then get your own copy of the token by calling DuplicateTokenEx().  Once you have the token, you can get rid of the suspended temporary process.

At a later time, when you need to launch a process as a specific user, you can call CreateProcessWithTokenW() to launch the process.

The above solution will not work on Windows XP since CreateProcessWithLogonw() isn’t supported. You may be asking why you don’t just call CreateProcessAsUser() instead of CreateProcessWithTokenW() since you have a token from CreateProcessWithLogonW().  The reason is because CreateProcessAsUser() requires the “Replace a Process Level Token” right for the caller which even Administrators do not have by default.  (This avoids granting any additional rights to the caller for this technique to work).

Unhandled System.IO.PathTooLongException when doing certifications with WACK 3.1 tool

$
0
0

 

Writing to cover an issue that has been occurring in the certifications recently.   The basic issue is the certification tool will attempt to do checks on the setup packages that are compressed files to ensure the files are compiled with security checks in place. When the path is exceeding 248 characters, the tool will automatically fail the Windows security features test.

 

 

The final certification report may show the following in the log:

 

Windows security features test

FAILED

Binary analyzer

·         Error Found: The binary analyzer test detected the following errors:

·         Impact if not fixed: If the app doesn’t use the available Windows protections, it can increase the vulnerability of customer's computer to malware.

·         How to fix: Apply the required linker options - SAFESEH, DYNAMICBASE, NXCOMPAT, and APPCONTAINER - when you link the app. See links below for more information:
Fixing Binary Analyzer Errors

 

In further review, you may see something like the following in the BinScope_trace_post_process_xxx.log:

Program Information: 0 : Plugin of type MsiSplitter loaded.
Program Information: 0 : Plugin of type ZipSplitter loaded.
System.IO.InvalidDataException: The file could not be unpacked (the error returned was: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.). ---> System.IO.PathTooLongException: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
   at System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength)
   at System.IO.Path.GetDirectoryName(String path)
   at Microsoft.MSEC.BinScope.Plugins.ZipUnpackStreamContext.OpenFileWriteStream(String path, Int64 fileSize, DateTime lastWriteTime)
   at Microsoft.Deployment.Compression.Zip.ZipEngine.UnpackOneFile(IUnpackStreamContext streamContext, ZipFileHeader header, Stream& archiveStream)
   at Microsoft.Deployment.Compression.Zip.ZipEngine.Unpack(IUnpackStreamContext streamContext, Predicate`1 fileFilter)
   at Microsoft.MSEC.BinScope.Plugins.ZipSplitter.GetSubitems(String path)
   --- End of inner exception stack trace ---
   at Microsoft.MSEC.BinScope.Plugins.ZipSplitter.GetSubitems(String path)
   at Microsoft.MSEC.BinScope.BinScopeScanner.Traverse(String path, List`1 checks)
   at Microsoft.MSEC.BinScope.BinScopeScanner.ExecuteChecks(List`1 checkTypes, String path)
   at Microsoft.MSEC.BinScope.BinScopeScanner.ExecuteChecks(List`1 checkNames, String path)
   at Microsoft.Windows.SoftwareLogo.Tests.Msec.Binscope.ExecuteTestInternal(TaskData taskData)
   at Microsoft.Windows.SoftwareLogo.Tests.Msec.Binscope.ExecuteTest()

 

In order to resolve the issue, shorten the file paths that are in the embedded compressed files that are in the desktop setup program to prevent going beyond the 248 characters from being reached. When doing so, the Windows Application Certification Kit will be able to at least be able to complete the testing process for processing the setup to provide the opportunity for a passing result.

Thank you,

Nathan Manis

RegSaveKey() is failing with error ERROR_NO_SYSTEM_RESOURCES (1450)

$
0
0

One of our senior emea Windows SDK Engineer, Nitin Dhawan, got an interesting issue where an application was failing to save a registry key to a file on local disk using RegSaveKey(). Investigating further, he found that the API RegSaveKey() was failing with Win32 error 1450 as reported by GetLastError().

 Winerror.h has details about error 1450 as below-

 //

//
MessageId: ERROR_NO_SYSTEM_RESOURCES

//

//
MessageText:

//

//
Insufficient system resources exist to complete the requested service.

//

#define ERROR_NO_SYSTEM_RESOURCES       1450L

 Registry APIs use paged-pool memory for its operations. Paged-pool memory is limited on the machine and shared by multiple components on the system. So if the memory allocation request by RegSaveKey() is not
successful, it returned with error ERROR_NO_SYSTEM_RESOURCES. This may happen even if the paged-pool memory is available but it is fragmented in a way that there is no single block of free memory available to fulfill the request. 

In this issue, RegSaveKey() was failing with ERROR_NO_SYSTEM_RESOURCES, because the size of the registry key was about 16MB which application was trying to save to the file on local disk.

Note: This link on MSDN has information about Registry Element Size Limits (Windows) . For a registry value the recommendation is less than 1 MB of size or any value more than 2KB should be stored in file and application should be using the file not the registry.

 The error ERROR_NO_SYSTEM_RESOURCES may happen in other scenarios as well, references as kb article links provided below:

You receive error 1450 "ERROR_NO_SYSTEM_RESOURCES" when you try to create a very large file in Windows XP

http://support.microsoft.com/kb/913872

Backup program is unsuccessful when you back up a large system volume

 http://support.microsoft.com/kb/304101

 Written by: Nitin Dhawan, Senior Support Engineer

Blog Reviewed by: Jeff Lambert(Sr. Escalation Engineer)

  

 

Encountering "The client and server cannot communicate, because they do not possess a common algorithm" or SEC_E_ALGORITHM_MISMATCH (0x80090331)

$
0
0

Typically when a Client and Server communicate via SSL/TLS, they must use a common cipher algorithm.  If they are unable to find a common algorithm, the SSL/TLS connection will fail with the exception, "The client and server cannot communicate, because they do not possess a common algorithm" using the SSLStream class.  Internally, SSLStream calls AcquireCredentialsHandle() which fails with SEC_E_ALGORITHM_MISMATCH (0x80090331).

I recently encountered the following issue.  My customer was trying to use one of the following ciphers between a client & server:

  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA

When attempting to use any of the above ciphers, the server was failing.  If they used any of the following algorithms, it worked fine:

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

It turns out you can encounter this error (SEC_E_ALGORITHM_MISMATCH) if the server’s certificate KeySpec poperty is set to 2 (AT_SIGNATURE).   A certificate with this KeySpec is only good for signing.  This is why the (EC)DHE Key Exchange Algorithms worked.

The cipher suites of choice using the RSA key exchange is for the KeySpec to be set to 1 (AT_KEYEXCHANGE). 

Once this change was made, the server was able to use the first 4 specified algorithms.

Rejoice! We can now capture loopback traffic.

$
0
0

Hey guys, Jeff here.

I work on a lot of networking cases, and the last thing I
ever want to hear is that a customer’s application is using local network
traffic - either by using the loopback address, 127.0.0.1, or just the public IP
address but the client and server both reside on the same machine.

Most tools, like Wireshark and Netmon aren’t able to capture
data that didn’t actually go out on the wire. Windows is smart enough that it
doesn’t send traffic destined for itself all the way down the stack to the
wire. There have been a few tools that allowed you to capture loopback data,
but nothing with the weight of the Windows product team behind them.

Until now. Message Analyzer
is the eventual replacement to Network
Monitor
and offers lots of new capture features. The one I am talking about
today is the local/loopback capture.

Here we can see that it knows the source and destination
addresses are the loopback address, 127.0.0.1


 

To capture loopback traffic, open Message Analyzer, and
create a New Blank Session.

On the next screen, we get to choose if we are going to
start a live capture or open some files. Click Live Trace.

To get the loopback traffic, we are going to use the
Firewall provider. Add it and click OK, then click Start on the New Session
dialog.

That’s all there is to capturing local loopback traffic now.

Happy Capturing!

 

 

Winsock server application not accepting new connections

$
0
0

Jeff here, from the Windows SDK team.

Recently, I had a case involving a client server application. My customer writes software that is deployed to thousands of other
customers and only 2 were having this problem, so it probably wasn’t a code problem. The server side of the application would stop accepting new socket
connections, but would still service existing connections. Networking traces and ETL showed that the server would return a RST packet to every SYN connection
attempt. This only affected the customer’s service, and not SMB or RDP connections.

The customer didn’t have much logging in the accept code, but it was clear that we weren’t getting normal accept requests. It was also
reported that this happened after a network outage that involved a link failover.

After we implemented lots of logging in the accept connection code, we saw that we were receiving Winsock error 10054, WSAECONNRESET,
An existing connection was forcibly closed by the remote host, even though we were the one resetting the connection. After several weeks of troubleshooting,
a quick search returned a very valuable KB article.

An application may receive the "10054" error when the application receives data from a connection on a computer that is running Windows 7 or
Windows Server 2008 R2 if a TDI filter driver is installed
, KB 981344.

The customer did have a TDI filter driver installed, TrendMicro OfficeScan, and they were running Windows 2008 R2.

The resolution was to enable the regkey, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\TdxPrematureConnectIndDisabled.

A change was made in Vista that prevented us from sending too many connection attempts in a short time through TDI, similar to SYN attack
protection. Enabling this regkey allowed all the simultaneous connections caused by the network outage to reach the server application.

 

Windows Firewall interfaces, INetFwProducts, and InetFwProduct.

$
0
0

 

Jeff here again. Today I have samples of the Windows Firewall interfaces, INetFwProducts, and InetFwProduct.

#include "stdafx.h"
#include <windows.h>
#include <stdio.h>
#include <netfw.h> 

#pragma comment( lib, "ole32.lib" ) 

// Forward declarations

HRESULT    FWProductsCOMInitialize(INetFwProducts** ppFwProducts); 

int _tmain(int argc, _TCHAR* argv[])
{
    HRESULT hrComInit = S_OK;
    HRESULT hr = S_OK;
    long cnt = 0;
    INetFwProduct *pFwProduct = NULL;
    INetFwProducts *pFwProducts = NULL; 

    // Initialize COM.

    hrComInit = CoInitializeEx(0, COINIT_APARTMENTTHREADED );  

    if (hrComInit != RPC_E_CHANGED_MODE)
    {
        if (FAILED(hrComInit))
        {
            printf("CoInitializeEx failed: 0x%08lx\n", hrComInit);
            goto Cleanup;
        }
    } 

       hr = FWProductsCOMInitialize(&pFwProducts);

    if (FAILED(hr))
    {
        goto Cleanup;
    } 

       hr = pFwProducts->get_Count(&cnt);

       if (SUCCEEDED(hr))
       {
              printf("get_Count: %d\n",cnt);
              hr = pFwProducts->Item(cnt - 1 , &pFwProduct);

              if (SUCCEEDED(hr))
              {
                     BSTR bsDisplayName = NULL;
                     hr = pFwProduct->get_DisplayName(&bsDisplayName);

                     if (SUCCEEDED(hr))
                     {
                           printf("Display name: %S\n", bsDisplayName);
                           SysFreeString(bsDisplayName);
                     } 

                     BSTR bsExe = NULL;

                     hr = pFwProduct->get_PathToSignedProductExe(&bsExe);

                     if (SUCCEEDED(hr))
                     {

                           printf("Path to signed exe: %S\n", bsExe);
                           SysFreeString(bsExe);

                     }

 

                     IUnknown *pUnkNewEnum;                    
                     hr = pFwProducts->get__NewEnum(&pUnkNewEnum);

                     if (SUCCEEDED(hr))
                     {

                           IEnumVARIANT*pUnkVariant;

                           hr = pUnkNewEnum->QueryInterface(IID_IEnumVARIANT,(void**) &pUnkVariant);

                           if (SUCCEEDED(hr))
                           {

                                  do
                                  {

                                         ULONG celt=1;
                                         VARIANT var1[1];
                                         VariantInit(&var1[0]);
                                         ULONG CeltReturned=0; 

                                         hr = pUnkVariant->Next(celt,&var1[0],&CeltReturned); 

                                         if (SUCCEEDED(hr))
                                         {

                                                if(S_FALSE==hr)
                                                {
                                                      //noop possible

                                                }
                                                else
                                                {

                                                       switch (var1[0].vt)
                                                       {

                                                           case VT_UNKNOWN:
                                                              case VT_DISPATCH:

                                                              {
                                                                     INetFwProduct  *pFwProductQI = NULL;
                                                                     HRESULT hrQI;
                                                                     hrQI =var1[0].punkVal->QueryInterface(IID_INetFwProduct, (void**)&pFwProductQI);

                                                                     if(SUCCEEDED(hrQI))
                                                                     {

                                                                           HRESULT hrDisplayName;

                                                                           BSTR displayNameEnum;

                                                                           hrDisplayName = pFwProductQI->get_DisplayName(&displayNameEnum);

                                                                           if(SUCCEEDED(hrQI))

                                                                           {
                                                                                  printf("\nEnum Display Name: %S\n", displayNameEnum); 

                                                                                  //clean-up

                                                                                  SysFreeString(displayNameEnum);

                                                                                  VariantClear(&var1[0]);

                                                                           }

                                                                     }

                                                              }

                                                              break;

                                                       default:

                                                              break;

                                                       }

                                                }

                                         }

                                  }

                                  while(hr !=S_FALSE && !FAILED(hr));

                           }

                     }

              }

       }

 

Cleanup:

 

    // Release INetFwPolicy2

    if (pFwProduct != NULL)
    {
        pFwProduct->Release();
    }

     // Uninitialize COM.

    if (SUCCEEDED(hrComInit))
    {
        CoUninitialize();

    }  

    return 0;

HRESULT FWProductsCOMInitialize(INetFwProducts** ppFwProducts)

{
      HRESULT hr = S_OK;

 

    hr = CoCreateInstance(         __uuidof(NetFwProducts),

        NULL,

        CLSCTX_INPROC_SERVER,

        __uuidof(INetFwProducts),

        (void**)ppFwProducts);

     if (FAILED(hr))
    {
        printf("CoCreateInstance for INetFwProducts failed: 0x%08lx\n", hr);

        goto Cleanup;       

    } 

Cleanup:

    return hr;

For these APIs to work, the Windows Firewall Service needs to be running, otherwise get_Count() returns a bogus number. These APIs only work with 3rd party firewalls, they won’t return the Microsoft firewall.

 

Follow us on Twitter, www.twitter.com/WindowsSDK.

 

/Jeff


How to interoperate between SSPI and the .NET NegotiateStream Class

$
0
0

Win32 Desktop Applications can take advantage of SSPI to authenticate Windows Users.  In .NET, Windows Authentication can be done using the NegotiateStream Class.

http://msdn.microsoft.com/en-us/library/system.net.security.negotiatestream(v=vs.110).aspx

We have had several questions in the past on how you can get a Win32 Desktop Client/Server Application using SSPI to authenticate with a .NET Client/Server using the NegotiateStream Class.

The key to getting these Frameworks to interoperate is that the NegotiateStream Class has implemented its own PROTOCOL which wraps SSPI.  This means that you need to modify your Win32 Application to implement the PROTOCOL before sending your SSPI Blobs to the NegotiateStream Client/Server.

Luckily, the NegotateStream Protocol is documented here.  (Referred to as [MS-NNS]: .NET NegotiateStream Protocol)

http://msdn.microsoft.com/en-us/library/cc236723.aspx

The key thing to review are the Message Syntaxes which are the following:

  • Handshake Message
  • Data Message

For the Handshake Message, the message is defined here:

http://msdn.microsoft.com/en-us/library/cc236739.aspx

This information should allow you to easily modify your desktop application using SSPI to interoperate with an .NET application using the NegotiateStream Class.

Follow us on Twitter, www.twitter.com/WindowsSDK

Hotfixes for September 2014

$
0
0

Here are some hotfixes that were published in September 2014.

2990833 Downloading stops at 99 percent in Xbox Video in Windows 8.1 and Windows Server 2012 R2

2990830 The Psxss.exe process stops intermittently on a server that is running Windows Server 2012

2990372 "Device does not exist" error after you reinsert a USB COM port device

2990170 Multipath I/O identifies different disks as the same disk in Windows

2989936 An NTFS volume is flagged as dirty after each restart, and CHKDSK can find no issues

2989586 Stop error 0x000000D1 after you install the Hyper-V role on a computer that's running Windows Server 2012

2987843 Memory usage of AD FS federation server keeps increasing when many users log on a web application in Windows Server 2012

2987452 Performance issues when you use credential roaming on RD Session Host servers in Windows 7 or Windows Server 2008 R2

2985459 The W3wp.exe process has high CPU usage when you run PowerShell commands for Exchange

2983488 "DRIVER_POWER_STATE_FAILURE (9f)" error when you use the native VPN connection and then shut down or suspend the computer

2981841 Internet Explorer freezes for several minutes and loads websites slowly in Windows 7 or Windows Server 2008 R2

2979583  Additional thick line is printed on a page that has an Excel chart in Windows 7 or Windows Server 2008 R2

2977728 Computer is on low memory when you move a video file in Windows 7 or Windows Server 2008 R2

2977285 Custom page size is ignored when a printer use a V4 printer PostScript driver in Windows 8.1 and Windows Server 2012 R2

2974735 Slow PXE boot performance on a UEFI computer that's running Windows 8.1 or Windows Server 2012 R2

2970215 Microcode update for Intel processors to improve the reliability of Windows Server

2957699 Confusing message from Work Folders in Action Center when you change or disconnect the network in Windows 8.1

2957477 The account password is not changed when a local account on a terminal server that is running Windows Server 2008 is connected remotely to the server

2935389 System shows a high nonpaged pool utilization from pool tag AfdP

2888853 FIX: "The supplied message is incomplete" error when you use an FTPS client to upload a file in Windows

2752618 RDS client computer cannot connect to the RDS server by using a remote desktop connection in Windows

/Jeff

Follow us on Twitter, www.twitter.com/WindowsSDK.

High-resolution timestamps and hardware in Windows

getnameinfo() WILL use NetBIOS for name resolution

$
0
0

Jeff here again from the Windows SDK team.

A customer pointed out an inconsistency in some MSDN documentation and I wanted to mention it here while the documentation bug works its way through editing.

According to the documentation for gethostbyaddr(), getnameinfo() will not use NetBIOS to do name resolution. This is incorrect. The following paragraph is wrong:

Although gethostbyaddr() no longer recommended for use as of Windows Sockets 2 and the getnameinfo() function  should be used, gethostbyaddr() is capable of returning a NetBIOS name;
getnameinfo() is not. Developers requiring NetBIOS name resolution may need to use gethostbyaddr() until their applications are completely independent of NetBIOS names.

The TechNet page for Network Application Interfaces has this table:

The gethostbyaddr() or getnameinfo() functions use the following (default) address look-up sequence:

1. Check the Hosts file for a matching address entry.

2. If a DNS server is configured, query it.

3. Send a NetBIOS Adapter Status Request to the IP address being queried. If it
responds with a list of NetBIOS names registered for the adapter, parse it for
the computer name.

A network trace shows the NBNS request:

10.53.4.255         10.53.18.120       NBNS    92           Name query NBSTAT
*<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>

 

/Jeff

Follow us on Twitter, www.twitter.com/WindowsSDK.

Job Object Insanity

$
0
0

Job Objects were introduced to Windows in Windows XP/Windows Server 2003 to allow an application to manage a group of processes.

One of the limitations of Job Objects is that a process can only belong to a single Job object.  This becomes an issue when you are attempting to manipulate a process which is already associated with a Job Object.  A process can be associated with a Job object through inheritance or via assignment (AssignProcessToJobObject API).  If you call AssignProcessToJobObject() to assign a Job to your process and it is already associated with a Job Object, the API will fail with error code 5 or "Access Denied".  (Note, error code 5 could have another meaning).

It turns out that Windows uses Job Objects for various scenarios such as:

  • A process launched via the Run As Command (This is implemented by calling CreateProcessWithLogonW. CreateProcessWithTokenW() is a similar API except for it uses a token for the user's identity)
  • Remote Desktop Client setting (mstsc.exe), "Start a Program"
  • The Task Scheduler

Based on the way Job Objects are designed, it may not be possible to disassociate a process from a Job.  (This is referred to as BREAKING AWAY)

If the Job wasn't created with JOB_OBJECT_LIMIT_SILENT_BREAKAWAY_OK or if the child wasn't launched with CREATE_BREAKAWAY_FROM_JOB + JOB_OBJECT_LIMIT_BREAKAWAY_OK, the process will not be able to disassociate from a Job.

If you can obtain a handle to the the Job Object, you could change the future behavior of the child process so that it could be broken away.  This requires the Job object to be named and the caller has to have the permissions to modify the Job object.  (This may not always be possible).

To address this limitation on Windows 8/Windows Server 2012, you can associate a process with more than 1 Job via a Nested Job.

See the following for more information on Nested Jobs:

http://msdn.microsoft.com/en-us/library/windows/desktop/hh448388(v=vs.85).aspx

 

Windows 10 (Threshold) Changes To The Windows Command Prompt

$
0
0

Jeff here from the Windows SDK team.

This blog isn’t network related, but something else that is close to my heart, the Windows Command Prompt. I have been using and supporting
Windows NT since version 3.51, and I don’t think the command prompt has changed in all that time. But Windows 10, build 9841, brings lots of long overdue
additions.

The first things I did to every install of Windows for the last 20 years was to enable QuickEdit mode, and increase the screen buffer
size. Now QuickEdit mode is enabled, and the buffer sizes are a much more reasonable 120 x 9001. That by itself is enough of a reason for the happy
dance, but wait, there’s more!

Windows 10 now has an experimental tab. The link below doesn’t have much information at the moment.

 

 

Enable line wrapping selection– Lets you select text on multiple lines, just like Word or
notepad.


Filter clipboard contents on paste
– How many times have you sent a command line to a customer and when they paste it into a command prompt it just doesn’t work correctly?
Usually this is because Outlook changes quotes and dashes.

“Now is the time for all good men to come to the aid of their country.”

Wrap text output on resize– Changes the text wrapping as soon as you resize a window. No more
re-running a command after you resize the window to see the new changes.

Enable new Ctrl key shortcuts– Ctrl+C and Ctrl+V now copy and paste just like every other app.
(Although I am partial to Ctrl+Insert and Shift+Insert, because I am left-handed.) Ctrl+A, Ctrl+F, and others also work as expected.

Extended Edit Keys
– Not much information is available on this yet.

Trim Leading zeros on selection– (Disabled by default) When selecting numbers with leading
zeros, the zero’s aren’t selected.

Numbers with a leading radix as still selected in their entirety.

Opacity– Lets you see through beneath it.

This information is based on an unreleased version of
Windows. Your mileage may vary.

/Jeff

Follow us on Twitter, www.twitter.com/WindowsSDK.

 

Unable to do Digest Authentication on Windows 8.1

$
0
0

Programmatic Digest Authentication can be done using the SSPI APIs with the WDigest Package.  See the following:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa380500(v=vs.85).aspx

On Windows 8.1, you may encounter the following error if you are using the SSPI APIs:

AcquireCredentialsHandle fails with the error code 0x8009030e (or SEC_E_NO_CREDENTIALS)

using the Default credentials on the client side.

On Windows 8.1 the Digest Package (WDIGEST) is disabled by default. You need to enable it via the registry.  See the following and take a look at the security section:

The Digest client does not cache credentials for domain members. Applications will prompt for credentials. You can enable caching in Digest clients with the following REG command:

 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\]

“UseLogonCredential” =dword:1

http://technet.microsoft.com/en-us/library/dn303404.aspx

 

Follow us on Twitter, www.twitter.com/WindowsSDK.

 


October 2014 Hotfixes

$
0
0

Jeff here from the Windows SDK team. This week was October 2014 patch Tuesday, here are some of the hotfixes that we published.

3000435 Virtual Machine Management Service memory leak triggers Windows Server 2008 R2 crash

3000406 Windows Journal crashes when you import a Word document that contains pictures Windows
7 or Windows Server 2008 R2

3000064 The computer restarts unexpectedly after you install security update MS14-045 on
Windows 7 or Windows Server 2008 R2

2999237 An application connection fails through a dual-use socket that is redirected by
using a WFP callout driver

2998984 You cannot dock MicroStation toolbars after you install update 2973201 in Windows

2998556 Windows Server 2012-based cluster freezes after you enable the data deduplication
feature

2998553 Too much UAL diagnostic information is logged in application event log in Windows
Server 2012 R2 or Windows Server 2012

2996883 DFSR stops replication after an unexpected shutdown in a Windows 8.1 or Windows
Server 2012 R2 environment

2996808 Gray conversion of the RGB color is printed incorrectly through a PCL 6 version 4
driver in Windows

2996807 Print jobs are intermittently processed slowly through Windows 8.1-based or Windows Server 2012 R2-based printer servers

2996534 Rotated images in PowerPoint 2013 are printed incorrectly when you use XPS in Windows

2996502 Sitka fonts cannot be printed correctly by using an XPS print driver in Windows

2996207 Network printers that use TCP/IP port cannot print after first document has printed in
Windows

2995392 Stop error 0x000000D1 after you install the Hyper-V role in Windows Server 2012 R2

2995054 "400 Bad Request" error when you send a message that contains a lowercase
"get" to the Gateway

2991247 SMB 3.0 Transparent Failover feature does not work after you disconnect a drive
cable in Windows

2991246 "Access is denied" error when you perform a backup or run "vssadmin list
writers" on a cluster node in Windows Server 2012

2988609 You cannot print fax by using a fax modem in Windows

2987849 Logon fails after you restrict client RPC to DC traffic in Windows Server 2012 R2 or
Windows Server 2008 R2

2981330 WTSQuerySessionInformation API function always returns zero bytes for WTSIncomingBytes and
WTSOutgoingBytes

2979583 Additional thick line is printed on a page that has an Excel chart in Windows

2968741 Error 0x80070057 when SQL Server communicates to a web server using stored procedure
in Windows 8 or Windows Server 2012

2873531 Checks that call the IsAlive and LooksAlive methods are not executed based on the
resource default settings in Windows

Bonus Hotfix!

2732597 0x80070091 error when you drag and drop a folder in a WebDAV shared folder in Windows

UPDATE: Yesterday I was kidding about the bonus hotfix. But it turns out 5 hotfixes were missing from the above list. Here they are:

2993228 0x00000093 Stop error when you enable the BranchCache functionality on a file server in Windows 8 or Windows Server 2012

2995055  Error 0x80070001 when you try to optimize a CSV volume in Windows Server 2012 R2

2995635  "DIR_Error" occurs when you try to obtain the properties of the RODC in a different domain

2957486 Ls command takes a long time to list shared files in two windows on a Windows Server 2008 R2-based NFS server  

2998097 "Specified account does not exist" error message when domain users try to change their password in UPN format in a different domain

/Jeff

Follow us on Twitter, www.twitter.com/WindowsSDK.

 

Disabling User Access Control (UAC) in Windows 8.X

$
0
0

I've recently come across several customers who were having issues with accessing a secured Windows Object as an Administrator.  They mention that this worked fine on Windows 7. 

Before I continue, I would STRONGLY RECOMMEND that you do NOT disable User Access Control for several reasons including:

  • Windows Store Applications will NOT run.
  • UAC forces your Administrators to run as Standard Users until it is necessary to be elevated.

In Windows 8.X, you can disable UAC via the User Account Control Settings Dialog Box with the following setting:

You'll notice that all this is really doing is configuring Windows to NOT notify you of the UAC Prompt.  In order to disable UAC on Windows 8.X, you must go through the registry or via a policy>

See the following link on the registry:

http://msdn.microsoft.com/en-us/library/cc232765.aspx

The registry key is:

Key: SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

Value: "EnableLUA"

Type: REG_DWORD

Data: This MUST be a value in the following table.

Value

Meaning

0x00000000

Disabling this policy disables the "administrator in Admin Approval Mode" user type.

0x00000001

This policy enables the "administrator in Admin Approval Mode" user type while also enabling all other User Account Control (UAC) policies.

For the policy, take a look at the following:

"How User Account Control Works"

http://technet.microsoft.com/en-us/library/jj574202.aspx

As I mentioned above, you shouldn't disable UAC.  Microsft offers developers and system admins various ways of working with UAC so you do NOT have to do this.  Please see the following white paper:

"The Windows Vista and Windows Server 2008 Developer Story: Windows Vista Application Development Requirements for User Account Control (UAC)"

 http://msdn.microsoft.com/en-us/library/aa905330.aspx

 Follow us on Twitter, www.twitter.com/WindowsSDK.

 

 

 

 

 

Debugging : The 9 Indispensable Rules for Finding Even the Most Elusive Bugs

$
0
0

Jeff from the SDK team here again. I debug both customer’s code and Windows on a daily basis with WinDBG and other tools. I recently came
across a fantastic book by David J. Agans called Debugging : The 9 Indispensable Rules for Finding Even the Most Elusive Software and
Hardware Problems.

This book doesn’t cover any debugging tools, but rather different ways to think about problems, and how each one can help you be a more
productive problem solver. It offers real world ‘war stories’ from his many years of hardware and software design. It is only 175 pages and can be read in
just a few hours.

The 9 Debugging rules are, with the briefest of paraphrased explanations are:

1)     Understand the system – Read the manual, you can’t fix something unless you know how it is supposed to work.

2)     Make it fail – I have always used this one, but I called it, “If I can make it worse, I can make it better.

3)     Quit Thinking and Look – Don’t just think about the problem, add debugging, hook up a scope, get your hands dirty.

4)     Divide and Conquer – Keep dividing the search area in half, make it hard for the bug to hide.

5)     Change One Thing at a Time – Don’t try to find bugs with a shotgun, use a rifle instead.

6)     Keep an Audit Trail – Keep detailed notes on how you reproduced a bug, it makes it easier on everyone to find it and fix it.

7)     Check the Plug – Start at the beginning, don’t just start debugging where you think the bug might be.

8)     Get a Fresh View – Run a difficult problem passed a colleague or even your mother. Talking fixes as many problems as the
debugger does.

9)     If You Didn’t Fix It, It Ain’t Fixed – You have to understand why your fix resolved the problem. If not, keep looking.

David has a website, it hasn’t been updated in a while but it does have a nice PDF of the 9 Debugging Rules to hang on your wall.

/Jeff

Follow us on Twitter, www.twitter.com/WindowsSDK.

The FileSystemWatcher Buffer Size

$
0
0

Jeff again from the Windows SDK group.

.NET offers something called the FileSystemWatcher
that monitors a folder for changes and updated in files.

While the watcher itself is reliable, customers frequently
report that they are not seeing changes. The most common reason is that the
changes exceeded the buffer
size
. The default buffer size is only 8,192 bytes. The important thing to
remember is that file names allocated from this buffer size. If you are using long
file names, you can’t store many file changes in 8K. The maximum is 64K, and
should be allocated in 4K increments. Events received when the buffer is full
are lost.

From MSDN:

The system notifies the component of file
changes, and it stores those changes in a buffer the component creates and
passes to the APIs. Each event can use up to 16 bytes of memory, not including the file name. If there
are many changes in a short time, the buffer can overflow. This causes the
component to lose track of changes in the directory, and it will only provide
blanket notification. Increasing the size of the buffer can prevent missing
file system change events.

Save yourself the headache of missing events in the future,
increase the buffer size now to 64K.

/Jeff

Follow us on Twitter, www.twitter.com/WindowsSDK.

Programmatic Smartcard Logons in Windows

$
0
0

There are several ways for an application to generate a user's token via a programmatic Smartcard Logon in Windows.  The simplest way is via a call to LogonUser() which typically takes credentials via the user's password.  You can also utilize LogonUser() to do a SmartCard logon by marshaling the SmartCard Certificate on the system with the user's PIN though the CredMarshalCredential API - http://msdn.microsoft.com/en-us/library/windows/desktop/aa374801(v=vs.85).aspx.

The LogonUser API is just a wrapper around LsaLogonUser() so internally when using LogonUser() + CredMarshalCredential().  Your application can do the same programmatic Smartcard logon directly yourself via the KERB_SMART_CARD_LOGON structure - http://msdn.microsoft.com/en-us/library/windows/desktop/aa378133(v=vs.85).aspx. with LsaLogonUser().

In addition, it is possible to map several Windows Users to a single Smartcard.  Windows will display the following User Interface.

To programmatically implement a Smartcard Logon where it is mapped to multiple Windows users can be done via LsaLogonUser() with the KERB_CERTIFICATE_LOGON structure - http://msdn.microsoft.com/en-us/library/windows/desktop/bb545680(v=vs.85).aspx.

Is there any reason why you would choose to do a programmatic logon using LsaLogonUser() instead of LogonUser()?

The only reason is if you are doing this from the LocalSystem security context or you need to do a smartcard logon where the smartcard is mapped to multiple users. 

LogonUser() for smartcard logons doesn't work for the LocalSystem Account.  Other than that, LsaLogonUser() has stricter security requirements such as require the SeTcbPrivilege and it is much more complex. 

I would choose the LogonUser() route myself since it is simpler and I like simple code.

 

 

Viewing all 126 articles
Browse latest View live