Session.xml keeps getting deleted

Ivan Rei

@PeterJones , Hi, thanks for the reply and sorry for not adding the versions. I think everything @ner00 stated below is basically what happened to me. I was on version 8.6.4 and the problem started with ± version 8.6.2.

I always shutdown Notepad++ first and then I shutdown the machine as I have done for many years and it only started happening with these past versions.

I have just installed 8.6.5 and hopefully this problem gets resolved with that. I’ll let you know.

Thanks so much!!!

xomx

@ner00 @Ivan-Rei

From both of your reports it does not appear to be a flashback of the previous Windows shutdown issues where the N++ was still running.

@ner00 said in Session.xml keeps getting deleted:

I have also enabled Windows’ audit policy to try and figure out what process is deleting the session file

A big thumbs up for getting the SACL involved to find the cause of the problem.

But reading this means that it cannot be some external problem (some external app deleting that N++ session.xml file…). This report says:

"Note: I just noticed that the computer at work, which never lost its session,
 is still on v8.6.2, so maybe that's why this machine doesn't have the same issue. "

so the search for the problem should be narrowed down to changes in v8.6.3-8.6.4.

Edit:
@ner00
My logic is flawed - it can be some external app problem - your two computers do not have exactly the same SW installed for sure (?). Could you upgrade also your ok-workstation to v8.6.4 and watch?

But my version-searching note is still valid.

ner00

@xomx said in Session.xml keeps getting deleted:

My logic is flawed - it can be some external app problem - your two computers do not have exactly the same SW installed for sure (?). Could you upgrade also your ok-workstation to v8.6.4 and watch?

But my version-searching note is still valid.

The logic is not flawed, assuming Npp itself is the root cause, I believe it is but then I would also assume that a lot more people would be reporting it. If not, it could very well be a third party software, although I’m not completely sold on that either (just yet).

Apart from the OS and a few common tools, like Npp, the two computers have very different software, yes.

I just installed v8.6.4 on the non-problematic machine (which was on v8.6.2). Let’s see if it eventually starts happening with this one.

Edit:
@xomx
There is also an important factor that usually slips my mind, I first reported having this issue on February 10th, that was a week prior to v8.6.3 being released.

ner00

Unfortunately I couldn’t catch anything worthwhile with SACL and Event Viewer.

session.xml vanished again (still on v8.6.4) and the Windows’ audit logs were too many to even span longer than 24 hours. I had already increased the security logs size to 500MB, but Windows seems to have had a spike of too much worthless auditing by default and that fills up pretty quick.

Anyway, just updated now to v8.6.5, recover the session from one of my daily backups (although last modified on the 4th). Will wait and see… might increase the security logging to 10GB if this keeps happening, or regress to v8.5; don’t know yet, probably in that order.

mkupper

@ner00 Do you have the ability to set up a script that watches to see if the Notepad++.exe process is running and also watches to see if the Session.xml file exists? You would log every time an instance of Notepad++.exe starts or disappears and every time Session.xml appears or disappears.

Check every few seconds and log when you see changes. The goal is to see if there is a correlation between Notepad++.exe and Session.xml.

You can check for processes named Notepad++.exe from a command prompt batch file using PSTools from Microsoft Sysinternals.

ner00

@mkupper Thanks for the suggestion.
I could do that without much effort, with tasklist alone even… although Powershell may be more practical and effective.

The reason why I’m trying Windows Audit as a first option is twofold:

If a third-party process is responsible for this, this will let me know exactly which;
It’s possible that the issue happens at shutdown, there’s a slim chance for my script to catch the event before being killed itself.

But thinking of it while I type this, it probably wouldn’t hurt too much to run a script like the one you suggested; logging every time Npp is opened, closed, and also checking whether session.xml exists or not.

For now, I have increased Windows’ security logging size to 10GB - overkill… I wonder if it loads when full - and also have updated Npp to v8.6.5.

If a repeat happens, and Windows audit logs aren’t clear, then I might go with your suggestion before attempting a downgrade. I really would like to get to the bottom of this.

ner00

This post is deleted!

mkupper

@ner00 @ner00, is your session.xml file getting deleted or converted to a zero length file?

I took at look at Notepad++ v8.6.5. On startup Notepad++ opens the session.xml file with read access, reads it, and closes it.

On exit Notepad++:

Copies the existing session.xml file to session.xml.inCaseOfCorruption.bak. As part of this it also copies the time stamps from the session.xml file to session.xml.inCaseOfCorruption.bak.
Opens the session.xml file with read/write access, truncates it to zero length, writes the config, closes it, opens it back up, reads the file (I assume to verify that it contains the expected data), and closes it.

Notepad++ never deletes or renames the session.xml file.

Do you leave Notepad++ running at the time you log out or shut down? Also, are you asking for a clean logoff/shutdown or forced?

Is there a file named nppLogNulContentCorruptionIssue.log in the same directory as the session.xml file? If not then create an empty file named nppLogNulContentCorruptionIssue.xml in the same directory as Notepad++.exe.

When nppLogNulContentCorruptionIssue logging is enabled then Notepad logs some stuff in nppLogNulContentCorruptionIssue.log when it is asked to close/exit due to a logoff or shutdown event. Normally it adds nine lines that would look like this:

2024-04-06 16:32:00  WM_QUERYENDSESSION (lParam: 0 - ordinary system shutdown/restart) =====================================
2024-04-06 16:32:00  WM_ENDSESSION (wParam: TRUE, lParam: 0 - ordinary system shutdown/restart)
2024-04-06 16:32:00  c:\npp\Settings\config.xml is opened.
2024-04-06 16:32:00  c:\npp\Settings\config.xml  10379/10379 bytes are written.
2024-04-06 16:32:00  c:\npp\Settings\config.xml is closed.
2024-04-06 16:32:00  c:\npp\Settings\session.xml is opened.
2024-04-06 16:32:00  c:\npp\Settings\session.xml  4884/4884 bytes are written.
2024-04-06 16:32:00  c:\npp\Settings\session.xml is closed.
2024-04-06 16:32:00  WM_DESTROY (isEndSessionStarted == true)

If you do a shutdown that asks for forcing applications to exit then the first two lines will be:

2024-04-06 17:05:01  WM_QUERYENDSESSION (lParam: 1073741824 - ENDSESSION_CRITICAL) =====================================
2024-04-06 17:05:01  WM_ENDSESSION (wParam: TRUE, lParam: 1073741824 - ENDSESSION_CRITICAL)

Even in the force-close mode Windows gives applications a few seconds to do a clean exit and cleanup. That typically is more than enough time for Notepad++.

When you do a normal Alt+F4 exit then Notepad++ does not update nppLogNulContentCorruptionIssue.log.

Edit to add a note on how the nppLogNulContentCorruptionIssue.log data was gathered. From the command prompt I did:

shutdown /l is a logoff. This is logged as

2024-04-06 16:14:31  WM_QUERYENDSESSION (lParam: 2147483648 - ENDSESSION_LOGOFF) =====================================
2024-04-06 16:14:31  WM_ENDSESSION (wParam: TRUE, lParam: 2147483648 - ENDSESSION_LOGOFF)
...

shutdown /s /t 0 /d p:00:00 is a normal shutdown which is logged as ordinary system shutdown/restart as detailed above.

shutdown /s /t 30 /d p:00:00 is a shutdown that forces applications to quit. Any non zero value for /t will do this. The default for /t is 30 which is why I used /t 0 to initiate a normal shutdown.

It’s a little strange in that Microsoft defines that if you give a people a heads up that a shutdown is coming by using /t # that the resulting application quits are forced. Also, it appears that applications are not signaled when you first run shutdown with a value such as /t 180. Instead, a dialog box pops up warning the humans to save their work. Windows signals the applications 180 seconds later with a forced quit. If you use /t 0 the shutdown is immediate but as part of this the applications are signaled and given plenty of time to wrap things up. I did not test this today but from what I recall, if an application then ignores the signal to quit that Windows aborts the shutdown timer and tells the human about which application is stuck and gives them a choice on waiting, forcing it to quick, and quitting the shutdown.

ner00

@mkupper I appreciate all the suggestions, but I eventually stumbled upon the reason for my issue, which I covered in detail in GitHub. I am not sure if other users such as @Ivan-Rei have the same root cause, but it is a possibility.

For the sake of it, I’ll also post here the answer to my issue:

Notepad++ v8.6.5 solves my problem, but not because the previous versions were its cause… but rather due to the implementation of session.xml.inCaseOfCorruption.bak to recover from a corrupt or missing session.

Using Windows SACL to audit/monitor session.xml interactions finally paid off, and the offender is a third-party app. Below is the Windows Event that logged the deletion of session.xml last night (Event Time: 2024-04-12T21:05:21.8234573Z [UTC+01:00]):

An attempt was made to access an object.

Subject:
	Security ID:		SYSTEM
	Account Name:		DESKTOP-S4VK9SM$
	Account Domain:		WORKGROUP
	Logon ID:		0x3E7

Object:
	Object Server:		Security
	Object Type:		File
	Object Name:		C:\Users\ner0\AppData\Roaming\Notepad++\session.xml
	Handle ID:		0xc10
	Resource Attributes:	S:AI

Process Information:
	Process ID:		0x4660
	Process Name:		C:\Program Files\Dell\SupportAssistAgent\SRE\SRE.exe

Access Request Information:
	Accesses:		DELETE

	Access Mask:		0x10000

Dell’s SupportAssist has been in my system forever, but it was updated January 17th 2024, which is just a couple weeks or so before I started having this issue of losing Npp’s session.

I looked a bit deeper into this.
I started by opening SupportAssist’s interface and checked the history, there I found the following actions:

In my attempt to find more concrete details, I ended up finding logs in C:\ProgramData\Dell\SupportAssist\SRE\ExtendedLogs, there were two log files from last night, their naming scheme is in the form of a GUID prefix, followed by two suffixes and date/time:

_ScanDiskCleanerResult_2024_04_12_22_05.txt
_FixedDiskCleanerResult_2024_04_12_22_05.txt

Both of these log files contain this specific line (verbatim):
c:\users\****\appdata\roaming\notepad++\session.xml, 25,36 kb, 1, noteplusplus, application

I have no clue why or how SupportAssist started “cleaning” files that it clearly doesn’t understand their purpose, sloppy management at Dell being my best guess. I don’t even care for their cleaning routine, I just have it for the system drivers and BIOS updates.

I am not entirely sure how to disable the cleanup job, for now I went to SupportAssist’s Settings > Scans and optimizations where there are scheduled scans for various things, one of which is Test system performance which includes a on/off toggle for Automatically boost performance, optimize network settings, and remove viruses and malware - I disabled this hoping that it stops doing weird crap like deleting Npp’s session. Contacting Dell to try to solve this seems futile, there are forum threads in their community about the aggressive cleanup job and they have gone unanswered for years.

I hope this can be useful to someone else, but even if not, session.xml.inCaseOfCorruption.bak will probably “solve” it. Just make sure to update to v8.6.5 or above.

By the way, this was the XML query that I used in Windows’ Event Viewer to filter the Security logs for this particular purpose:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
	*[System[(EventID=4663)]]
	and
	*[EventData[Data[@Name='ObjectName'] and (Data='C:\Users\ner0\AppData\Roaming\Notepad++\session.xml')]]
	and
	*[EventData[Data[@Name='AccessMask'] and (Data='0x10000')]]
    </Select>
  </Query>
</QueryList>

mkupper

@ner00 said in Session.xml keeps getting deleted:

session.xml.inCaseOfCorruption.bak

@donho may be feeling lonely and so should be happy to get a kudo for implementing the session.xml.inCaseOfCorruption.bak file thing.

It is concerning that manufacturer installed services are now deleting Notepad++ data files.

Google for "noteplusplus" "session.xml" only finds this forum thread. I used “noteplusplus” as that’s the name Dell SupportAssist uses. Google for "SupportAssist" "session.xml" finds this forum thead and one other page which looks like a spurious hit. I can’t find the string “session.xml” on it.

Thank you for posting that filter XML. I had forgotten about the XML tab in event viewer’s filter dialog box. It’s useful to keep in mind. We were lucky in that the offending application was deleting your support.xml so regularly.

Is SupportAssist running under your login or is it a Window service? If it’s a service you set up security on your session.xml to only allow access for you. I’d suggest an ACL to deny access but those take precedence and it can get painful if you accidentally deny access to yourself.

ner00

@mkupper I’m very grateful for the introduction of a session backup file and recover mechanic, which would eventually solve my problem regardless of me being able to get to the bottom of my issue, so kudos are indeed due. Then again, the whole piece of software is so amazing that, no matter what, the respect for it is a constant.

Regarding Dell’s SupportAssist, I can vividly recall that it had never deleted Npp files in v3.x of the software, but when they pushed v4.x noteplusplus became visible in the cleanup logs, session.xml individually targeted since February 9th 2024. With that in mind, this is so niche and recent that it may not have raised enough awareness among Dell users. Myself took almost 2 months to figure it out, and it happened about once per week (“optimization” job is scheduled to run every Friday).

As for ACL rules to prevent that from happening, it doesn’t seem feasible. The service from SupportAssist runs as a service with SYSTEM privileges, I can’t shield the session file from that. Even if I were to edit the service to run under a dedicated login user, it would probably either revert at some point in time or start failing due to lack of privileges on other operations like driver updates and such system-sensitive operations.

ner00

@mkupper said in Session.xml keeps getting deleted:

It is concerning that manufacturer installed services are now deleting Notepad++ data files.

As a side note, @xomx mentioned this in the GitHub issue that I raised:

@xomx said in Lost my last session (all my temporary files are not reopened) #14707:

I am guessing that someone at Dell just needed to delete their “session.xml” file as part of some maintenance task and used a method to do so that probably also deletes such external app files…

Which is probably what it is, simply a short-sighted approach that recursively deletes session.xml. Either that, or it’s a targeted Npp deletion with no rhyme or reason that I can think of…

I can’t be bothered to disassemble Dell’s binaries to find out, but I doubt it would cause enough uproar to make them code better.

Note: Maybe MS payed Dell to sabotage Npp in hopes to promote VS Code or Win11 MS Notepad. [joking]

Alan Kilborn

Perhaps it goes without saying at this point, but for any future topics of this nature, it should be asked of posters if they have a Dell machine (and then more questions from them if the answer is in the affirmative).

donho

@Ivan-Rei
Could you confirm that you have Dell’s “Support Assist” installed ?

donho

Yet another confirmation:

https://community.notepad-plus-plus.org/topic/25629/notepad-release-8-6-5/17?_=1713198544329

ner00

I’m not expecting to get anywhere with this, but gave it a try anyway: https://www.dell.com/community/en/conversations/supportassist-for-pcs/supportassist-v4-cleanup-deletes-sensitive-data/661d48d8fcb3f754c1d59938

donho

@mkupper said in Session.xml keeps getting deleted:

@donho may be feeling lonely and so should be happy to get a kudo for implementing the session.xml.inCaseOfCorruption.bak file thing.

LOL!
I love kudo, but all kudos should go to @xomx - thanks to his code review, the workaround of Dell Support Assist’s bug has been implemented in v8.6.5:
https://github.com/notepad-plus-plus/notepad-plus-plus/pull/14858#issuecomment-1999912317