Hex editor plugin crashes Notepad++ on startup when opening nfo files

[Fourbits]

If the hex editor plugin is installed, Notepad++ invariably crashes on startup when I open any file with the .nfo extension through the context menu in Windows; however, it doesn’t happen if Notepad++ is already open. I’ve seen this thread, where others were unable to reproduce the problem, but I’ve found this to be easily reproducible:

1. Install the hex editor plugin from the plugin manager or from here
2. Close all instances of Notepad++
3. Find any .nfo file, create an empty .nfo file, or apply the .nfo extension to any file
4. Right-click on the file and select “Edit with Notepad++” from the context menu
5. Watch Notepad++ open and close without an error message

I’m using the latest 32-bit version of Notepad++ on Windows 10. Any ideas why this would happen?

[Ekopalypse]

@Fourbits

did you test whether this happens if hex editor plugin is your only plugin also?

[PeterJones]

@Fourbits

Along with what @Ekopalypse suggested (trying with only the hex editor plugin)…

you said,

I’m using the latest 32-bit version of Notepad++

Unfortunately, that’s not as descriptive as you might think. The problem is, the latest (as of Jan 16) is v7.8.3. But if you have v7.8.2 and click ? > Update Notepad++, it won’t download an update, because the developer hasn’t yet (as of Jan 27) set the flag on the v7.8.3 release to push it to the auto-installer (it’s usually a 1-2wk delay, to make sure there are no critical regression bugs before forcing it on everyone). And sometimes, we find that the person asking the question had turned off auto-updates (accidentally or otherwise unknowingly), so was even farther behind in version number, but because there hadn’t been a version push, they thought they were on the newest version.

The best thing to do whenever asking for help in this forum, especially for something that might be version-dependent, is to include the output from ? > Debug Info > Copy debug info into clipboard and paste it in your question (or in a response, in this case).

Other pieces of information that might be useful:

• What do you consider a .nfo file? The thread you linked has some that are just plain text (similar to a readme file), and some that are fancy ASCII-art files. Does the crash happen when you name a plain text file blah.nfo and open it as described? Does it happen with ascii-art-based .nfo files (using the box-drawing characters, etc)?
• What is the exact text of the Windows association for “Edit with Notepad++”?
  • You can search your registry (regedit.exe) for that text. If there is an underscore under one of those letters in your menu, like _E_dit with Notepad++, then use an & before the character in your search (like &Edit with Notepad++). If you are still having trouble finding it, maybe just search for Notepad++ or &Notepad++ in the registry, until you find the “Edit with Notepad++” entry.
  • If that still doesn’t do it, disable the HexEditor plugin, then right-click on your .nfo file, and Edit with Notepad++, then once Notepad++ is successfully launched, use Ctrl+Shift+ESC to pull up your task manager, go to Details tab; if there isn’t a Command line column, RClick on the Name column header, Select Columns, and scroll down and enable Command line. While you are hovering over the Command Line cell in the notepad++.exe row, you should see something akin to:
    
    Do an Alt+PrtScn and paste into your reply (or, like me, paste into mspaint.exe, crop just the part you desire, then copy/paste into your reply).
• What encoding is Notepad++ trying to pick for the .nfo file? Maybe that encoding confuses the Hex Editor plugin. And is Notepad++ interpreting it as “MSDOS Style / ASCII Art”. (If you cannot tell, disable Hex Editor, reload the .nfo with RClick>Edit with Notepad++, and look in the status bar – or Alt+PrtScn the status bar for us). Or maybe syntax highlighting for the “MSDOS Style / ASCII Art” lexer is interfering with the Hex Plugin (though since Settings > Style Configurator > DOS Style only has a DEFAULT style, that would surprise me that it would conflict).

[PeterJones]

To expand on what I just said,

What do you consider a .nfo file?

If you have a short .nfo file that you can share, open it in a non-Hex-Editor Notepad++, select all, Plugins > MIME Tools > Base64 Encode, select all and copy, paste into the forum… That way, we can all have the same file you’re using.

[Fourbits]

@PeterJones

did you test whether this happens if hex editor plugin is your only plugin also?

Yes. I have tested it on two different computers with and without the default plugins alongside the hex editor plugin.

The best thing to do whenever asking for help in this forum, especially for something that might be version-dependent, is to include the output from ? > Debug Info > Copy debug info into clipboard and paste it in your question (or in a response, in this case).

In order to test out the problem more, I did a fresh install of v7.8.3, retaining no custom settings from previous installs, but it is not an issue new to this version. Here is my debug info as of this moment:

Notepad++ v7.8.3 (32-bit)
Build time : Jan 12 2020 - 19:05:42
Path : C:\Program Files (x86)\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS Name : Windows 10 Enterprise (64-bit)
OS Version : 1903
OS Build : 18362.592
Plugins : HexEditor.dll mimeTools.dll NppConverter.dll NppExport.dll

What do you consider a .nfo file?

Literally anything with the .nfo extension – a proper Windows System Information file, ASCII art, a regular text file, or a completely empty file of length 0. As I mentioned in my original post, you can take any file and add .nfo to the end, and it will crash. You can also take any kind of .nfo file and give it a different extension, and it will open without issue.

What is the exact text of the Windows association for “Edit with Notepad++”?

I’m assuming you want the path listed in the registry:
C:\Program Files (x86)\Notepad++\notepad++.exe

What encoding is Notepad++ trying to pick for the .nfo file?

I can provide three examples. The first is literally an empty file called test.nfo:

The next is a System Information file with just the metadata:

PD94bWwgdmVyc2lvbj0iMS4wIj8+DQo8TXNJbmZvPg0KPE1ldGFkYXRhPg0KPFZlcnNpb24+OC4wPC9WZXJzaW9uPg0KPENyZWF0aW9uVVRDPjAxLzI4LzIwIDA2OjI3OjUyPC9DcmVhdGlvblVUQz4NCjwvTWV0YWRhdGE+DQo8L01zSW5mbz4

Here’s a text file, created in Notepad++:

aGVsbG8

Some other things I’ve noticed:

• As mentioned in the OP, opening an .nfo from the context menu (or in any other way) works as long as Notepad++ is already open, but it will always assume the encoding is OEM-US, regardless of what it actually is
• Opening the same file from the context menu without opening Notepad++ first will crash it every time
• If you change the extension to .txt and reopen it, it will load with the correct encoding
• If you change the file’s encoding while editing it, it will convert and display correctly until you close the program
• If an .nfo file is open in a tab, you can close and re-open Notepad++, and it will load the tab without issue if it is not unicode
• If Notepad++ decides any file’s “language” is “MSDOS Style / ASCII Art” and the encoding is unicode (any kind), closing the program with that tab open will make it impossible to open the program again, because it will crash every time. This can be fixed with any of the following methods:

1. Editing %AppData%\Roaming\Notepad++\session.xml to remove the tab’s entry
2. Changing lang="MS-DOS Style" to lang="Normal Text" in that entry
3. Changing encoding="-1" to encoding="437" in that entry
4. Deleting the hex editor plugin from the plugins folder

• It always assumes that a file with the .nfo extension is “MSDOS Style / ASCII Art,” and it usually guesses that a zero-length file’s encoding is UTF-8, but if I just take the same file and rename it with the same extension, it may guess a different encoding

[PeterJones]

@Fourbits,

Thank you for the additional information.

Unfortunately, I cannot* install 32-bit Notepad++ in such a way that I replicate your environment.

(* = while at work: at all; when at home: without messing up my super-tweaked configurations. Actually, at home, I think I have a virtual windows machine where I can install a 32bit installation, and thus get the normal registry commands… I’ll see if I have time tonight, if you haven’t had a chance to confirm/contradict the below experiments)

In the meantime, if you are willing to run more experiments, here are a couple ideas I had, based on your answers…

I’m assuming you want the path listed in the registry:

Yes, I wanted that. I also wanted to see if there were other options set in your association; based on the screenshot you showed, it doesn’t look like it.

EXPERIMENT: If the file is not open in Notepad++ and Notepad++ is closed, what happens if you run the same "C:\Program Files (x86)\Notepad++\notepad++.exe" "D:\Google Drive\nfo\test.nfo" from the command line rather than from the Windows RClick open? Does it still crash?

(My idea here is to see whether it’s the hex-editor-crashes-npp-during-load, or whether it’s the extra layer that Windows association/right-click adds to the system that is causing it to crash)

Changing encoding="-1" to encoding="437" in that entry

QUESTION/EXPERIMENT: What is the setting of Settings > Preferences > MISC. > Autodetect character encoding? If it is on, try turning it off and trying to open the .nfo file.

(My idea here is that it’s Notepad++ trying to auto-detect or change the encoding while HexEditor is already trying to process the .nfo file)

Changing lang="MS-DOS Style" to lang="Normal Text" in that entry

It’s looking more and more like it’s the specifics of how Notepad++ uses the MS-DOS style. I’d love to be able to tell Notepad++ that .nfo is plain-text, rather than MS-DOS Style. Unfortunately, you can add an extension to most of the lexers (except plain text / default) in Settings > Style Configurator > Language: xxx > User Ext:, but you cannot remove an extension from the default extension list in the GUI. However, if you add nfo to the User ext: list for a different language lexer (including UDL), that will override the default language for that file extension. There are thus three workarounds that I can think of, which will convince Notepad++ that .nfo are not MS-DOS Style, and thus maybe make it so that Notepad++ MS-DOS Style lexer won’t conflict with the HexEditor plugin:

EXPERIMENTS:

• Remove nfo from the default extension list for MS-DOS Style. This involves editing langs.xml
  1. Close all .nfo files.
  2. Close Notepad++
  3. Open Notepad++
  4. Open %AppData%\Notepad++\langs.xml
  5. Search for ext="nfo" and change to ext="xnfo"
  6. Save
  7. Close Notepad++
  8. Try the RClick to open blah.nfo with Notepad++
• Assign nfo to some other builtin language:
  1. Close all .nfo files
  2. Settings > Style Configurator
  3. In Language column, pick some different language than Dos Style – maybe Search result. Add User ext.: nfo, then Save & Close
     • I don’t know whether any of those other lexers will similarly interfere with HexEditor. You may need to experiment with other languages if the problem persists with your first choice.
  4. Open blah.nfo from inside this instance of Notepad++. Make sure the status bar lists User Defined language file - PlainNFO, and/or Language > PlainNFO is selected.
  5. Close all .nfo files
  6. Close Notepad++
  7. Try the RClick to open blah.nfo with Notepad++
• Assign nfo to a UDL instead
  1. Close all .nfo files
  2. Language > User Defined Language > Define your Language
  3. Create New…: PlainNFO
  4. Ext.: nfo
  5. Don’t need to bother with setting any stylings
  6. Close UDL dialog/pane
  7. Open blah.nfo from inside this instance of Notepad++. Make sure the status bar lists User Defined language file - PlainNFO, and/or Language > PlainNFO is selected.
  8. Close all .nfo files
  9. Close Notepad++
  10. Try the RClick to open blah.nfo with Notepad++

Between the experiments, you probably want to undo what was done in the previous experiment.

(My idea with these is to try to eliminate the MS-DOS lexer from the equation)

[PeterJones]

@Fourbits,

I said,

at home, I think I have a virtual windows machine

Sorry, I didn’t get a chance until this weekend.

I spun up the VM, and did a fresh install of v7.8.4-32bit. I can confirm your symptoms.

I ran the five experiments I suggested:

• Experiment cmd.exe: hmm, the default “Edit With Notepad++” connects to DLL, not EXE. Still, "c:\Program Files (x86)\Notepad++\notepad++.exe" file.nfo crashes
• Experiment autodetect: turn encoding autodetect off: crashes
• Experiment 1: remove extension from langs.xml: Fresh RClick is okay
• Experiment 2: associate with Search Results rather than DosStyle: Fresh RClick is okay
• Experiment 3: associate with dummy UDL “PlainNFO”: Fresh RClick is okay

So, any of the three experiments which tried to convince Notepad++ that a .nfo file wasn’t MSDOS-Style/ASCII-ART was successful in preventing the crash.

If you do not need the default lexer trying to apply the default color of black on white to all text (ie, doing nothing helpful), I’d suggest implementing one of those three options to get around the buggy interaction between HEX-Editor Plugin and Notepad++'s NFO lexer.