Windows Killing Cortana Virtual Assistant

In a latest support document, Microsoft has announced the end of support for its virtual assistant Cortana in Windows starting August 2023. Though Cortana will continue to be available in Outlook mobile, Teams mobile, Microsoft Teams display, and Microsoft Teams rooms, this move signals Microsoft's roadmap to tread away from the Cortana ecosystem and venture into other AI-powered tools that it has started bundling with Bing (Chat AI) and Office 365 (Office 365 Copilot). They have also introduced Windows Copilot with its latest preview of Windows 11 in June 2023.

In January 2015, Microsoft announced the availability of Cortana for Windows 10 desktops and mobile devices as part of merging Windows Phone into the operating system at large. In my personal experience an Acer Aspire V 15 V3-574-7481 running Windows 10 was the first laptop that I used Cortana on. It was interesting but I was not impressed as much as the Google Voice Assistant. I have always kept it disabled on my devices since then.

Over the years Cortana has also been bundled in several 3rd-party voice-activated devices like Harman Kardon's INVOKE speakers, ecobee smart-thermostats, Johnson Controls Glas thermostats, Nest smart-thermostats Honeywell's Lyric and Total Connect Comfort smart-thermostats, LIFX smart-lights, TP-Link Kasa smart plugs, and Geeni smart home devices, Philips Hue smart-lights and Wink smart home devices.

In the last few years, Microsoft has removed Cortana from the Xbox, iOS and Android.

Microsoft's 2nd June 2023 statement on their support website is here.

Rich Woods writes about it here at XDA Developers.

Calling WTSQueryUserToken() gives ERROR_PRIVILEGE_NOT_HELD in Windows Vista

Here I will describe an error called ERROR_PRIVILEGE_NOT_HELD that I faced from a call to WTSQueryUserToken() using Visual C++ on Windows Vista and Windows XP SP2.

I have used the WTSQueryUserToken() function to obtain the primary access token of the logged-on user whose session-id I had obtained from a call to WTSGetActiveConsoleSessionId().

Now, here is my problem. After the call to WTSQueryUserToken() from inside a DLL that is running under the Print Spooler service, GetLastError() returns error number 1314 which means: A required privilege is not held by the client. I am logged in to Windows using an administrator account. The Notepad.exe application that is invoked at the end of the code also doesn't start.

In MSDN I see that what I'm getting is the error ERROR_PRIVILEGE_NOT_HELD which means: The caller does not have the SE_TCB_NAME privilege. How should I go about getting that privilege now?

Print Spooler (SPOOLSV.EXE) runs under the SYSTEM username account, i.e., the LocalSystem account. A quick look up in the Windows Task Manager shows that the Image Name SPOOLSV.EXE is running under the SYSTEM username.

My DLL is loaded by SPOOLSV.EXE under its own context. My intent is to start the Notepad.exe application under the context of the user who is currently logged in to Windows.

Note: As an aside, note that the SPOOLSV.EXE runs from location C:\WINDOWS\system32\spoolsv.exe. It is the Windows Print Spooler service that loads files to memory for later printing.

Here is my source code snippet:

static STARTUPINFO si;

static PROCESS_INFORMATION pi;

HANDLE hTokenNew = NULL, hTokenDup = NULL;

DWORD dwSessionId = WTSGetActiveConsoleSessionId();

WTSQueryUserToken(dwSessionId, &hTokenNew);

DuplicateTokenEx(hTokenNew, MAXIMUM_ALLOWED, NULL,

                 SecurityIdentification, TokenPrimary,

&hTokenDup);

ZeroMemory(&si, sizeof(STARTUPINFO));

si.cb = sizeof(STARTUPINFO);

si.lpDesktop = _T("winsta0\\default");

LPVOID  pEnv = NULL;

DWORD dwCreationFlag = NORMAL_PRIORITY_CLASS | CREATE_NEW_CONSOLE;

CreateEnvironmentBlock(&pEnv, hTokenDup, FALSE));

dwCreationFlag |= CREATE_UNICODE_ENVIRONMENT;

pEnv = NULL;

ZeroMemory(&pi, sizeof(PROCESS_INFORMATION));

CreateProcessAsUser(hTokenDup, NULL, _T("c:\\windows\\notepad.exe"),

                    NULL, NULL, FALSE, dwCreationFlag,

                    pEnv, NULL, &si, &pi);

CloseHandle(hTokenDup);

Update 2007-04-25: So, this is how I solved it. There was no need for the WTSGetActiveConsoleSessionId() and WTSQueryUserToken(). Just the CreateEnvironmentBlock() must work properly so that the environment for the process you are going to create is set correctly.

Here is the source that worked for me. The code snippet below shows the Notepad application being launched. The DLL in which I used this code runs under the Print Spooler service - basically it is a Print Monitor. You need to add your own validity checks - what's listed below is bare-bones.

#include "userenv.h"

// Global Typedefs for function pointers in USERENV.DLL

typedef BOOL (STDMETHODCALLTYPE FAR * LPFNCREATEENVIRONMENTBLOCK)

             (LPVOID  *lpEnvironment,

              HANDLE  hToken,

              BOOL    bInherit);

typedef BOOL (STDMETHODCALLTYPE FAR * LPFNDESTROYENVIRONMENTBLOCK)

             (LPVOID lpEnvironment);

void InvokeApp()

{

    // Local Variable Declarations

    HANDLE hToken    = NULL;

    HANDLE hTokenDup = NULL;

    STARTUPINFO si;

    PROCESS_INFORMATION pi;

    ZeroMemory(&si, sizeof(STARTUPINFO));

    ZeroMemory(&pi, sizeof(PROCESS_INFORMATION));

   

    si.cb = sizeof(STARTUPINFO);

    si.lpDesktop = _T("Winsta0\\Default");

   

    DWORD  dwCreationFlag = NORMAL_PRIORITY_CLASS | CREATE_NEW_CONSOLE;

    LPVOID pEnvironment = NULL;

    LPFNCREATEENVIRONMENTBLOCK lpfnCreateEnvironmentBlock = NULL;

    LPFNDESTROYENVIRONMENTBLOCK lpfnDestroyEnvironmentBlock = NULL;

    HMODULE hUserEnvLib = NULL;

    hUserEnvLib = LoadLibrary(_T("userenv.dll"));

    if ( NULL != hUserEnvLib ) {

        lpfnCreateEnvironmentBlock = (LPFNCREATEENVIRONMENTBLOCK)

        GetProcAddress(hUserEnvLib, "CreateEnvironmentBlock");

       

        lpfnDestroyEnvironmentBlock = (LPFNDESTROYENVIRONMENTBLOCK)

        GetProcAddress(hUserEnvLib, "DestroyEnvironmentBlock");

    }

    OpenThreadToken(GetCurrentThread(), TOKEN_DUPLICATE, TRUE, &hToken);

    DuplicateTokenEx(hToken,

                     TOKEN_IMPERSONATE|TOKEN_READ|

                     TOKEN_ASSIGN_PRIMARY|TOKEN_DUPLICATE,

                     NULL,

                     SecurityImpersonation,

                     TokenPrimary,

                     &hTokenDup);

    RevertToSelf();

    CloseHandle(hToken);

    if (NULL != lpfnCreateEnvironmentBlock)

{

        if (lpfnCreateEnvironmentBlock(&pEnvironment, hTokenDup, FALSE))

{

            dwCreationFlag |= CREATE_UNICODE_ENVIRONMENT; // must specify

        }

        else

{

            pEnvironment = NULL;

            OutputDebugString(_T("CreateEnvironmentBlock() -- FAILED"));

        }

    }

    else

{

        OutputDebugString(_T("FAILED - GetProcAddress"));

    }

    CreateProcessAsUser(hTokenDup, NULL, _T("c:\\windows\\notepad.exe"),

                        NULL, NULL, FALSE, dwCreationFlag,

                        pEnvironment, NULL, &si, &pi);

   

    if (NULL != lpfnDestroyEnvironmentBlock)

        lpfnDestroyEnvironmentBlock(pEnvironment);

 

    if (NULL != hUserEnvLib)

        FreeLibrary(hUserEnvLib);

   

    CloseHandle(hTokenDup);

}

What did I fix? The issue I was facing was that the application I wanted my Print Monitor to launch using CreateProcessAsUser() was not getting the logged-on user's environment. The after-effect was that, because of this reason, when my application used to show the File Open common dialog box, it would behave strange while trying to browse to the Desktop in it. This was in Vista.

In Windows XP, the File Open dialog would let you browse to the Desktop folder but the object icons on the Desktop would not appear right in it.

Note that if you don't use CreateEnvironmentBlock(), and the application you launch uses things like the Windows Common Dialog boxes, you may find file dialog boxes working erratically.

Refer this and this.