I have PowerShell v2 installed on a windows XP SP3 machine and when I went to open PowerShell today it said:
The shell cannot be started. A failure occurred during initialization:
Object reference not set to an instance of an object.
The event in the Powershell event log is:
Soruce: Powershell
Category: engine health
Event ID: 103
Settings: Object reference not set to an instance of an object.
Details:
ExceptionClass=NullReferenceException
ErrorCategory=
ErrorId=
ErrorMessage=Object reference not set to an instance of an object.
Severity=Error
SequenceNumber=
HostName=ConsoleHost
HostVersion=2.0
HostId=0fba5d45-885f-4f19-a354-4b390d5605bd
EngineVersion=2.0
RunspaceId=db9879d6-247a-40d7-9bfe-5bfd07a973f0
PipelineId=
CommandName=
CommandType=
ScriptName=
CommandPath=
CommandLine=
Any idea what would cause this? it seems to randomly start.
This forum post seems to suggest a missing registry key in your profile.
Excerpts from the discussion
After analyzing the Process Monitor log again, I find this error occurred if the following Registry key was missing:
HKEY_CURRENT_USER\Environment
Eventually the user rebuilt his local profile.
I have also seen success with people running the following command in powershell
Set-ExecutionPolicy RemoteSigned
Related
IIS 10 will not restart on my PC. When I navigate to localhost, I get a 'localhost refused to connect' message. After looking through the event viewer, it turns out that the issue is that the Windows Process Activation Service (WAS) will not start.
The error message given is:
'The Windows Process Activation Service (WAS) encountered an error while handling key generation. This will prevent WAS from starting corrently. The data field contains the error number.'
When I try to start the service manually from the services app, I get the following:
Has anyone experienced this issue before? Any help would be greatly appreciated, I've been trawling the internet for several days trying to find a solution to no avail.
We've run into this issue several times after recent Windows Updates. In all cases, the following worked (got from a Microsoft support rep):
Run the following from an admin Powershell prompt:
reg delete HKLM\SYSTEM\CurrentControlSet\Services\WAS\Parameters /v GenerateKeys /f
net start w3svc
The keys will be regenerated, then the IIS AppPools can be started
According to your error message, WAS can not access the machine key when start up. Usually, machine keys are used to encrypt sensitive information in config file, WAS will not be able to start if there is no machine key to use.
The easiest and most common method is to try to uninstall and reinstall WAS.
If it still can not start, try to delete the registry entry NanoSet with cmd.
If the above two methods are useless, you can refer to this to delete machine keys, let WAS create new one while starting.
If somebody is still fighting with this issue, please check Event Viewer under System filter and check for any logs related to WAS. In my case I found the following entry:
The Windows Process Activation Service (WAS) encountered an error while handling key generation. This will prevent WAS from starting currently. The data field contains the error number.
So I just started again CNG Key Isolation service and everything is working now.
Lately I was having problem with WMI on one of the systems (win server 2019). Service list in Task Manager was empty and running Get-WmiObject Win32_Service from powershell was returning Generic failure. After fruitless hours of searching and trying to repair system I gave up and was ready to reinstall system. Then error was reproduced on another machine by accident and I was able to narrow down cause of the problem. After creating windows service with short name and short display name WMI brakes after system restart but only if that service is first (in alphanumeric order) on services list. To reproduce this effect you only need to run
sc create "A1" binpath="D:\foobar.exe" DisplayName="A1" start=disabled
binpath is irrelevant, service doesn't need to be started. DisplayName doesn't need to be identical to name. After that command you need to restart (before restart everything works). After that if you go to services list in task manager it will be empty (probably using WMI to query services list). Now you can run sc delete "A1" and reopen task manager. Everything is back to normal.
Problem was reproduced on Windows Server 2019 and Windows 10 (didn't tried on other versions).
Is this a known bug or what is happening here?
EDIT
I'm not asking about how to use sc. It's doesn't matter. I provided commands that someone can run to reproduce problem. You can create service with that parameters however you want.
You are using the sc command line arguments in the incorrect format.
From MSDN:
Optionvalue
Specifies the value for the parameter named by Optionname. See the Optionname reference for a list of supported values. When a string is to be input, the use of empty quotes means that an empty string is passed in. Note that there is a space between OptionValue and the equal sign.
The correct command should be:
sc create "A1" binpath= "D:\foobar.exe" DisplayName= "A1" start= disabled
I'm trying to use Powershell to get the NextRunTime for some scheduled tasks. I'm retrieving the values but they don't match up to what I'm seeing in the Task Scheduler Management Console.
For example, in the Task Scheduler console my "TestTask" has a Next Run Time value of "1/9/2018 12:52:30 PM". But when I do the following call in Powershell it shows "12:52:52 PM" for the NextRunTime.
Get-ScheduledTask -TaskName "TestTask" | Get-ScheduledTaskInfo
From what I've seen the seconds value is always the same value as the minutes when returned from the PowerShell Get-ScheduledTaskInfo cmdlet. I'm wondering if there's a time formatting error (hh:mm:mm instead of hh:mm:ss) in that cmdlet but I have no idea how to look for that.
The task is running at the exact time shown in the console so that makes me think that it's an issue with the powershell call.
Has anyone seen this issue before and know how to get the correct NextRunTime value in PowerShell? I'm also seeing the same issue with the LastRunTime value.
I've tried this on Windows Server 2016 and Windows 10 and get the same results on both operating systems.
I can confirm that I see the same issue on Server 2012R2 as well. You can get the correct information by using the task scheduler COM object, getting the root folder (or whatever folder your task is stored in, but most likely its in the root folder), and then getting the task info from that. Here's how you'd do it:
$Scheduler = New-Object -ComObject Schedule.Service
$Scheduler.Connect()
$RootFolder = $Scheduler.GetFolder("\")
$Task = $RootFolder.GetTask("TestTask")
$Task.NextRunTime
Probably also worth noting that you can use the Connect() method to connect to the task scheduler on other computers (if you have rights to access their task scheduler), and get information about their tasks, stop or start their tasks, make new tasks... lots of good stuff here if you don't mind not using the *-ScheduledTask* cmdlets.
We were trying to deliver a solution to manage a Windows 2012 server for a client using Chef, but unfortunately chef-client run failed with Chef::Exceptions::WindowsNotAdmin: can not get the security information for <some_file> due to missing Administrator privileges exception.
This was a bit weird as we have confirmed that the domain account we used to remotely manage the server is a member of the Administrators group. And we were able to use it to manage other servers within the same domain. Besides, when we connected to the server using the domain account via Remote Desktop, started PowerShell as an administrator and initiated a chef-client run, it failed with the same exception.
Running below commands reveals that the domain account is indeed a member of the Administrators group. This can be verified by the SID of the group.
Get-WmiObject -Class Win32_UserAccount
Get-WmiObject -Class Win32_Group
[System.Security.Principal.WindowsIdentity]::GetCurrent().Groups
Not sure what settings on the server could have caused this.
With insights provided by this thread, further digging into the code of Chef reveals that a win32 function GetNamedSecurityInfoW gets called here to determine the security information of an object (file, folder etc.). This occurs during cookbook installation where some resource files or gems need to be created on the endpoint server.
Firstly an empty file will be created, after that the file content will be updated atomically if that is an option. During file content update, the file’s security access control list needs to be checked by the function GetNamedSecurityInfoW. To call this function, the logged-on user needs to have a privilege SE_SECURITY_NAME. Chef itself also tries to handle this by adding this privilege before calling the function and revert it after the function call, but this is not always guaranteed. System settings seem to prevail.
We hacked Chef code a bit to try to print out the output of the function call on GetNamedSecurityInfoW, and it was a status code 1314, indicating a required privilege is not held by the user.
We tried to run whoami /priv on the server and found that SeSecurityPrivilege privilege is not found in the list. Below is just a sample output on a normal Windows server.
Privilege Name Description State
========================================================================
SeLockMemoryPrivilege Lock pages in memory Disabled
SeIncreaseQuotaPrivilege Adjust memory quotas for a process Disabled
SeSecurityPrivilege Manage auditing and security log Disabled
...
Note that the state column only indicates whether a privilege is being used by the user. It's existence indicates whether the user has it or not.
After adding back this privilege to the domain account, i.e. set the security setting of Manage auditing and security log to Administrators group in the Local Securtiy Policy editor, and rebooting the server, chef-client run became successful.
It seems that Chef is heavily using win32 API functions to manage Windows nodes. And these API functions seem to need various privileges to run. It's a bit strange that Chef rescued all win32 API errors and just propagated the Chef::Exceptions::WindowsNotAdmin to chef-client run log, as indicated here. It would be good to actually parse the error a bit and provide some more useful information.
I am having trouble when I have one Windows service try to install another Windows service.
Specifically, I have a TeamCity agent running tests for me on a Windows 2008 AWS instance. The tests are written in Java, which shell out to a .bat script to install a service (let's call it Service A), giving it a unique name each time.
The offending line is in the .bat script: sc create "%serviceName%" binPath= %binPath% DisplayName= "%serviceDisplayName:"=%" start= %serviceStartType%. I believe as long as the service name is unique that should work.
And indeed it does work if I run the tests manually on the command line, using an administrator account. Service A is installed, the test completes and Service A is uninstalled at the end.
I have tried running the TeamCity agent as LocalSystem, as Administrator, and as another user that is member of the administrators group. I have also tried disabling UAC completely.
Presumably the problem is access denied type errors, although that is not clear at this point. There are a few avenues to explore still, but it is a simple question really: are processes running as services forbidden from installing other services? Are there special things I have to do to configure the machine/ account to allow it to do this?
The point of the test it to install and use Service A, so workarounds are not relevant - Service A must be operated as a black box.
Thanks!
There are no restrictions on creating services with regards to how the creating process can execute, as long as the process has the appropriate permissions. That is to say, a process could be running as a service and create another service -- the only consideration here is the appropriate permission level.
The problem that often occurs with running batch scripts from within processes (as opposed to directly through user input on the command line) is that the environment expected isn't always the environment that is loaded. In this case, it appears that the env variables referred to in the batch script weren't properly set when running as a service, which of course then caused the service install failure. Correcting the environment loaded when the batch script is shelled out is the correct solution here.