I have all the settings as per https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/command-line-process-auditing
However, I am unable to see any 4688 events in my event viewer.This started happening when I updated my windows(I have windows 11). Has anyone faced a similar issue. Also, how do I make sure I have all the settings in place using command line?
KB5020044 Fixes Process Creation Audit Logging - Event ID 4688/1108 Issue
To resolve the issue, install the November 29, 2022—KB5020044 (OS Build 22621.900) Preview Cumulative Update.
Improvements:
It addresses an issue that affects process creation. It fails to
create security audits for it and other related audit events.
Related
My goal is to make sure I have a stable process for handling extension updates. I'm about to release a new extension and have noticed that the background service worker goes stale. Here are the details:
My method of testing this lifecycle is by generating a new build artifact and drag-n-dropping it into the page chrome://extensions. I hope this is the way to test this lifecycle. But if not, I would be happy to hear the alternative.
Once I drag and drop, I open the background console to check for the correct version, but seems it lags behind. The only way to remedy this issue is by removing the extension completely and loading it back, this gives me the impression a regular user would experience the same issue.
The screenshot below describes the situation:
version 0.3.33 is currently installed
drag and drop new build version 0.3.34
after successful drag and drop, notice version is lagging with version 0.3.31
But the chrome.runtime.onInstall release accurately outputs the previous version
Furthermore, I took a look at the unpacked extension directory and the compiled code is accurate with the expected version
What I've done so far to troubleshoot, was to remove the extension completely. It does successfully update after a series of manifest.version updates, but then it goes stale. To be clear, all I do is update the version property of the manifest.json file and that seems to cause this issue
Any help would be greatly appreciated. In the meantime, I'll brush up on the architecture for service workers as it relates to chrome manifest v3. Thanks!
EDIT - Sunday, August 22 2021:
The latest development:
First of all, thanks woxxom for additional details to debug.
I've created an example project that demonstrates the problem with reproducible steps. Hopefully, this helps identify the problem but it does seem to point to a Chrome bug so I'll also report it on crbug.com
Github project: https://github.com/miguelespinoza/-v3-service-worker-update
Ultimately, what I've identified is that loading an iframe causes the service worker lifecycle to go "stale".
Looking at chrome://serviceworker-internals/?devtools, I've noticed that the extension includes two workers, that seems odd because I'd imagine only one should exist, the one in the background. This could mean nothing, but wanted to share that as well. one "Active worker" and one "Waiting worker"
Important Note: Service worker background events stop working. In my case, chrome.commands.onCommand or chrome.action.onClicked
After upgrading system to Windows 10 - os 1803 we are getting below issues while working with ClearCase 8.0.1.x/9.0.1.x
Unable to checkin/checkout.
Not able to create views.
Not able to add any file to source control.
The system hangs & crashes while performing any ClearCase operation.
There is no error message, but I have attached screenshot for reference.
Please let us know if there is any issue with the Windows 10 ver(1803), any security system enabled?
Or has ClearCase provided any fix?
We have tried 9.0.1.5 and issue still persists.
This is what we got from windows event log.
The computer has rebooted from a bugcheck.
The bugcheck was:
0x000000c2 (0x0000000000000004, 0x00000000535be990, 0x000000000004efd3, 0xfffff803e01848b1)
for most of them whoever has upgraded to windows 1803 ver :( for people who are still using ver1709 it is working perfectly fine
Then I would recommand contacting IBM support: only them can update their ClearCase 9/Windows 10 compatibility matrix and confirm if MVFS is supported on a more recent (1803) Windows 10 edition.
We also facing same problem and I have raised the case with IBM. Still not yet resolved. As IBM said there are some limitations to work ClearCase with windows 10 and windows 2016.
We tried all the options except Secure boot disable. If possible please do disable secure boot option in Windows 10 and try to checkin/checkout code from CleraCase
Note : It works for Snapshot views. That means the issue related to MVFS
I'm seconding #VonC's recommendation to open a ticket with IBM. When you do that, save a step and collect a clearbug2 and a kernel memory dump to send in as soon as the case is opened. It will save the turn-around time of us asking you for it. If the installed programs list doesn't list installed security software (DLP, Privilege management sw like Avecto, other endpoint security tools), please list those separately as well.
I would also love to know who # IBM told you there are "limitations" with Win10-1803.
There are a few issues with Windows 10 "version upgrades" breaking things, but they generally don't cause system crashes. Windows 10 upgrades are actually full OS installs that then (imperfectly) migrate application settings. Anything that uses custom network providers (ClearCase is one example) will find that the network providers will be broken or partially broken. Reinstalling is usually required. Again, that has not yet been reported as a cause of a BSOD.
If the upgrade/reinstall didn't fix view creation, please post a separate question on the view creation issue. There may be things we can do to the SMB 2 caches to allow view creation to work in cases where the view storage is not on the client host.
I noticed that the screen shot you posted is a Terminal Services disconnect screenshot. Does the issue only occur over a Terminal Services client connection or does it also happen on a local connection?
For the last 3 days I have been trying to figure out how to install node.js. I tried every solution that I found on the internet, like disabling certain components during installation, installing both x86 and x64 etc, none of them worked.
My OS is Windows 10 x64. I tried different versions of node.js and they all return the same error shown in the screenshot below.
I tried installing through the command line and got the log. But I could not find anything useful from the log either. Please help.
The log can be found here: this path : https://drive.google.com/open?id=1OkkK36hlQeBX0xTNuOuilGaNr1u3S55e
MSI (s) (74:88) [20:49:45:955]: Executing op: ActionStart(Name=RegisterEventManifest,,)
MSI (s) (74:88) [20:49:45:961]: Executing op: CustomActionSchedule(Action=RegisterEventManifest,ActionType=3073,Source=BinaryData,Target=CAQuietExec,CustomActionData="wevtutil.exe" im "C:\Program Files\nodejs\node_etw_provider.man")
MSI (s) (74:A0) [20:49:45:969]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI33C1.tmp, Entrypoint: CAQuietExec
CAQuietExec: Error 0xc0000409: Command line returned an error.
This is the relevant part of the log and where the install keels over, noise removed. 0xc0000409 is very, very nasty. STATUS_STACK_BUFFER_OVERRUN is a stack corruption error, triggered by code that protects against viral attacks.
Searching for "nodejs install 0xc0000409" takes you to this bug report, notable from December 2015. This issue has been dogging users for a long time, but they are having trouble finding the root cause. The generic workaround is to disable this install step by disabling the installation of the ETW performance counters.
Which works, but is but a band-aid. I think macario1983's comment points at the real troublemaker. It got a lot of helpful votes in just two days. And points at the kind of viral rootkit that programmer's voluntarily install, the kind that can so easily cause a STATUS_STACK_BUFFER_OVERRUN error with no decent way to identify the code that causes it. Anti-malware has become a cure that is worse than the disease, Avast in particular is a truly awful product and does not belong on a programmer's machine.
So decent advice is to 1: disable the anti-malware product before installing Node. 2: get rid of completely if it is Avast. 3: disable the performance counter registration. 4: try the updated installer, patched 4 days ago.
I disabled the AVG antivirus(version 18.4.3056) but not windows firewall and then i was able to install nodejs.
Possible options to solve this:
1. Removing previous installations traces
If you have previous installations, make sure that they were uninstaled completely. If HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\_V2Providers\{1e2e15d7-3760-470e-8699-b9db5248edd5} record exist in your register, remove it.
2. Disabling Performance Counters
If you don't need Performance counters feature, try to install without it (or maybe even without Event Tracing).
3. Disabling security and giving the full permissions
Clean Temp Folder
Disable your antivirus/firewall for the period of installation.
C:/users/$user/AppData/Local/Temp- Right Click on Temp and go to Properties > select Security Tab > give the user permissions by checking Full Control on permission
Install Node.js
I had today the same problem with Windows 10 64 bit and Node.js 8.11.2: disabling completly Avast just for the time of the installation solved the issue.
I was trying to install Node.js through node-v8.11.2-x64.exe, but it was rolling back every time at the end. The error in the event log was about wevtutil.exe, version 10.0.17134.1
I had the same issue on a Windows 2012R2 server installing node-v8.11.2-x64, and disabled the McAfee anti-virus to no avail. When I went to clean out the TEMP folder as suggested in this thread, I noticed that several files and folders were locked and could not be deleted, so I rebooted the machine (with the anti-virus disabled). After the reboot, I noticed that the locked temp files had been deleted, and I was able to install node.js, including the Performance Counters and Event Tracking options.
I spent one day for that ....Best solutions is download zip example node-v12.16.2-win-x86.zip.
My Azure Functions were running fine and all of a sudden I am getting several "Assembly changes detected. Restarting host..." messages that is preventing my functions from completing.
I am not deploying new code so not sure what is triggering the Assembly Change event to fire. I was running on the latest version of the runtime and have since reverted to version 1.0.10947 thinking that maybe the underlying runtime was updated, but I'm still getting that line showing up in the logs.
Update
Now that #Alexey has helped me track down what is causing the Assembly changes to be detected. I would like to ask if anyone can tell me WHY an assembly change is being detected even-tough I have not changed/redeployed my application.
After looking in your logs we opened an issue https://github.com/Azure/azure-webjobs-sdk-script/issues/1533#issuecomment-303595960.
Your functions had multiple restores but now issue is gone. Restores could be initiated by changing project.json.
If you are stuck with the multiple
Assembly changes detected. Restarting host
I fixed my issue by deleted the log file in the Kudu services:
https://[FunctionAppName].scm.azurewebsites.net/
and follow on the top menu:
Debug Console >> powerShell
And the file log is :
LogFiles >> Application >> Functions >> function >> [Function name]
You can remove the log file.
my 2c.
I was struggling with this issue for ages and not sure what was causing it. I believe I may have the answer.
Our solution has been toying with consumption plans, but pulled back to full App Service Plans because the initiation times were too long for our rather unique usage patterns.
But 2 of the appsetting params were still in place: WEBSITE_CONTENTSHARE And WEBSITE_CONTENTAZUREFILECONNECTIONSTRING.
per:
https://learn.microsoft.com/en-us/azure/azure-functions/functions-app-settings#websitecontentazurefileconnectionstring
these are ONLY for consumption plans.
I removed them and... touch wood, the issue seems to be resolved.
I have a webAPI deployed on window azure, till last week I was able to run the WebAPI and debug but all of a sudden when I run the web application I get the below message.
Role instances are taking longer than expected to start. Do you want
to continue waiting?
And I tried to enable disable caching(default caching is disable) and also cleared the local storage but still the same issue persist, its happening in not only my machine but also on other dev machine as well. Could it be because of automatic software updates related to emulator or other SW or any other issue?
Happened withh me today. I ran into an issue of the Azure emulator not working. The roles were going in a continuous loop of Running, Busy and Suspended.
Initially I thought it might be due to some code I had changed . However, it turned out that a recent Windows update had caused this issue.
After spending a frustrating amount of time un-installing the recent updates one by one, I found the miscreant.
For Fix please un-install the Security Update KB3126593 (https://support.microsoft.com/en-us/kb/3126593).
While searching for the particular update, make sure you type “KB3126593” in the search bar. Typing 3126593 will not work.