PowerShell 7 Profile file content removed on Windows 11

[final bluff]

Howdy,
I just experienced and could reproduce the following:

• I used a PowerShell Notebook inside VSCode to set content to the $PROFILE.CurrentUserCurrentHost file as for the dotnet interactive host Microsoft.dotnet-interactive_profile.ps1
• I was able to confirm that the file content is set
• Some seconds later the file content was GONE, the file had 0 byte file size
• Repeat the steps
• Same results

What would be reverting the content of the profile file?

The device is onboarded into Defender XDR.

PS: I think I have experienced this in the past on another machine but I thought I just forgot to set the file content, but now I am not sure.

[twin ledge]

Does it work if you use set-content from within conhost?

[final bluff]

As this is scoped to the dotnet interactive notebooks only, the easiest way to set the profile for the notebooks is from a notebook. For the end users the best experience is just to hit run all on the top of the notebook meant to configure the environment. Btw, I use set-content in the notebook.

But I'll test what happens why I use the same code from the standard console.

[twin ledge]

Just to rule out some things about the issue .

That is just where I start because I'm not familiar with your work flow and the extensions you are using.

[stray magnet]

procmon it?

[north ferry]

Since the scope is the dotnet-interactive host, are you testing within that scope for content or are you using a Literal Path to test outside that scope for content? Unintentional reevaluation of $PROFILE.CurrentUserCurrentHost could easily confuse the situation. Just a thought.

[final bluff]

I am staying in scope. I have multiple notebooks which would rely on the same Profile. But even in my original notebook which I use to set the profile I can see that the file is set and ~30 seconds later the file is empty.

[median badger]

Weird, my $Profile.CurrentUserCurrentHost's profile hasn't changed since 2023.
However every patch moves the location AllUsersCurrentHost. ( It's outside vs code, so I think dotnet / runtime patches chage that )

Is yours something like C:\Users\nin\Documents\PowerShell\Microsoft.dotnet-interactive_profile.ps1 ?

To debug it, you could set a $PROFILE.CurrentUserAllHosts profile, and echo your $PROFILE.CurrentUserCurrentHost ?
That way you can verify it's where you expect . ( notebooks are weird )

CurrentUserCurrentHost: 'C:\Users\nin\Documents\PowerShell\Microsoft.dotnet-interactive_profile.ps1'
AllUsersCurrentHost: 'C:\Users\nin\.nuget\packages\microsoft.dotnet-interactive\1.0.607001\tools\net9.0\any\runtimes\win\lib\net8.0\Microsoft.dotnet-interactive_profile.ps1'

I tested that using new -> polyglot -> *.dib . I have regular defender

Maybe you can find something helpful in the polyglot logs

[final bluff]

I have a new machine, same setup, same results.

I have two notebooks:

• NotebookA: creates the Profile and runs set-content
• NotebookB: uses the profile

When NotebookB's kernel is started fresh or restarted the profile is still intact.
But when the first code block runs, even when it does nothing the profile is emptied out

Note sure how to read procmon, tbh

[shadow ore]

Run it (as admin) until the profile gets wiped
Stop capturing in procmon
Filter (Ctrl+L) = Path is C:\blah\blah\Microsoft.dotnet-interactive_profile.ps1

that'll at least tell you what process is actually clearing it

e.g. i made a manual edit to Microsoft.VSCode_profile.ps1

specifically this WriteFile operation wrote 33 bytes to the file (the total size of the file)

(the other write operation with a 4096 length is because my C drive has a 4k block size)

[median badger]

If MsMpEng is deleting the file, it might at least confirm that in event viewer. Try eventid 4660 / 4663

creates the Profile and runs set-content
Otherwise does the code that create the profile, exit if it already exists?
I was thinking another cell or kernel instance is running it again, truncating it.

---

I don't know if this is happening, but it could make a profile appear broken:

If MsMpEng scans the file -- it's a blocking operation -- preventing any I/O until it completes
That can make a terminal appear to lock up -- or not load a profile. when it's actually blocked and scanning.
( for a regular terminal it might show your prompt, but then not respond, not even ctrl+c until it finishes )

[shadow ore]

Oh i guess I'm blind and didn't see his screenshot of procmon oops