App crashes since update to 8.6.4.0 #14870
Comments
|
today a new appcrash: Problemsignatur Weitere Informationen über das Problem |
|
not closed due to new crashes |
|
From the supplied info (N++ v8.6.4, Release x64(?) build, Exception offset: 0000000000126f6e), I tried to deduce on which source code line the N++ crashes, it should be here: disassembly.text:0000000140126F13 call NativeLangSpeaker__getAttrNameStr.text:0000000140126F18 nop .text:0000000140126F19 mov r8, rbx .text:0000000140126F1C lea rdx, asc_14047C9E0 ; " " .text:0000000140126F23 mov rcx, rax ; Src .text:0000000140126F26 call std__basic_string_wchar_t_std__char_traits_wchar_t__std__allocator_wchar_t_____append .text:0000000140126F2B xorps xmm0, xmm0 .text:0000000140126F2E movups [rsp+138h+var_100], xmm0 .text:0000000140126F33 xor r13d, r13d .text:0000000140126F36 mov qword ptr [rsp+138h+var_F0], r13 .text:0000000140126F3B mov qword ptr [rsp+138h+var_F0+8], r13 .text:0000000140126F40 movups xmm0, xmmword ptr [rax] .text:0000000140126F43 movups [rsp+138h+var_100], xmm0 .text:0000000140126F48 movups xmm1, xmmword ptr [rax+10h] .text:0000000140126F4C movups [rsp+138h+var_F0], xmm1 .text:0000000140126F51 mov [rax+10h], r13 .text:0000000140126F55 mov qword ptr [rax+18h], 7 .text:0000000140126F5D mov [rax], r13w .text:0000000140126F61 mov [rsp+138h+var_108], ebx .text:0000000140126F65 lea r8, [rbp+70h+var_70] .text:0000000140126F69 lea rdx, [rsp+138h+var_100] .text:0000000140126F6E lea rcx, [rbp+70h+var_90] .text:0000000140126F72 call std__operator__wchar_t_std__char_traits_wchar_t__std__allocator_wchar_t____3 It does not seem like much to me - do you use the Project Panels N++ feature? Could you append here the info given by your N++ menu > ? > Debug Info... ? |
|
I do not use Project Panels N++ feature. |
|
@ulipp |
|
@donho disassembly (v8.6.4 x64 Release)// ::Sleep(DWORD(timer)); .text:0000000140126F66 mov ecx, eax ; dwMilliseconds .text:0000000140126F68 call cs:Sleep // isSnapshotMode = nppParam.getNppGUI().isSnapshotMode(); .text:0000000140126F6E cmp byte ptr [rbx+0AC5h], 0 ; rbx == &nppParam +2757 == &_isSnapshotMode (bool in the Parameters.h) So it could be something with the N++ backup feature or with an invalid ptr to the We can also send the user a new v8.6.4 x64 Release binary replacement build with the PDB ON (x64 Release > Linker > Debugging > Generate Debug Info > /DEBUG) and use the SysInternals ProcDump N++ launch monitoring for that 0xc0000005 access violation exception. |
|
@ulipp If you say yes, I will post here a zip-archive containing a v8.6.4 x64 Release binary substitute, which has been built from the original published v8.6.4 source code but with the debugging PDB, MAP and COD info-files generated for the Notepad++ exception crash minidump analysis later. There will be also two other files: Microsoft procdump64.exe and one batch cmd-file for launching that ProcDump exception monitor. It is also a must to have the admin-rights for copying that 3 files into your "C:\Program Files\Notepad++\" folder and opening the command-line window with the admin-rights too. |
I really don't see how parameter instance or _isSnapshotMode could be NULL. OTOH, you have just proved Notepad++ backup feature could crash due to dead lock. However, I think the current issue is an isolated case since we don't see any other crash report so far. |
Yes, I do not see that either yet but do not forget that like in the current BabyGrid bug, some other code could overwrite that variable address with something (or influence that rbx CPU register storing the nppParam base address somehow). I am also not entirely sure if I do the math about the crash source code address correctly from the available data (exception offset reported). We will see if @ulipp can help us further.
IDK if it is just me, but I seem to be seeing an increase in the user reports of losing the session file list these days, e.g.: https://community.notepad-plus-plus.org/topic/25563/notepad-keeps-losing-track-of-my-recent-files Maybe some current source code change causes that or it is simply a byproduct of that backup_mutex crash at the Windows exit with the N++ still running (such a crash will not be registered by users because it will only be visible in the Windows apps-log and if the backup_mutex crash occurs, the session.xml will not be saved at all - the N++ exit saving will not be there...). |
|
Issue #14707 that I opened doesn't seem to originate from a crash (then again, could be a silent crash during shutdown) . Also, I have been using Npp in at least 2 different machines for several years, they both have the same OS and Npp version, but just one of them started losing the session, seemingly at random, a couple times per month. Before mid-February, losing the session hadn't ever happened as far as I recall. One of the 2 machines is a workstation which is only shutdown/restarted once a month at most (this one hasn't lost a session ever), the 2nd one is my home machine, this one is shutdown every day, but it has only suffered from this issue 2 or 3 times in the past 45+ days. As per my description, I have uninstalled/reinstalled Npp 4 days ago, only time will tell. Note: If I line my experience with the releases, this issue should have started with v8.6.1, but on the other hand it doesn't really explain why one computer would have these rare session losses whereas the other doesn't at all, both fully updated around the same time. |
donho
changed the title
I am wondering if it cannot be influenced by some of the latest MS Windows updates or builds. Is that ok-workstation updated in the same way / intervals as that problematic 2nd machine? Or it can be only the statistic - your workstation is simply much less restarted than the problematic machine. |
|
I will try to note my actions immediately before an app crash. I use Notepad almost exclusively for creating Python and C# coding. It's also a replacement for the Microsoft Editor for me. If I notice anything, I'll let you know directly. |
That might be a possibility, but both machines are up to date, whether Microsoft pushes the same updates to all machines at the same interval is another question, but I believe them being about the same in that regard.
That could only be a partial view of the problem, I have had this machine for about 3 or 4 years, never had this happen before. I'll keep a closer eye on this, especially looking into the session XML file, the events in Event Viewer, in a 24h period of the issue happening again, if it does happen again. |
|
NO new crashes since updated to V8.6.5 - Thank you |
Description of the Issue
when using Notepad++ it crashes randomly
Steps to Reproduce the Issue
working with notepad
Expected Behavior
no crashes
Actual Behavior
random crashes
Debug Information
its running under 23H2 22631.3296
Plugins: Mime Tools, Npp Converter and NppExport
Name der fehlerhaften Anwendung: notepad++.exe, Version: 8.6.4.0, Zeitstempel: 0x65d3e0e7
Name des fehlerhaften Moduls: notepad++.exe, Version: 8.6.4.0, Zeitstempel: 0x65d3e0e7
Ausnahmecode: 0xc0000005
Fehleroffset: 0x0000000000126f6e
ID des fehlerhaften Prozesses: 0x0x46CC
Startzeit der fehlerhaften Anwendung: 0x0x1DA71F8FFBE952F
Pfad der fehlerhaften Anwendung: C:\Program Files\Notepad++\notepad++.exe
Pfad des fehlerhaften Moduls: C:\Program Files\Notepad++\notepad++.exe
Berichtskennung: aa361a62-84be-481c-8592-5ce8ce444302
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
The text was updated successfully, but these errors were encountered: