Hi Paul,
Little :) problem with x64 BETA 2 - (not a problem with x32 version)...
[File] [Open] {select a .bas file} [OK] ... WinFBE closes without error message
(even with a pristine download of WinFBE_Suite3-BETA-2.zip).
And FYI...
[Tools] [SetCompilerPaths] {error} ... (SetCompilerPathsII.exe (and .bas) don't exist).
Environment:
Win10-Pro x64 (ver)1803 (build)17134.799 i7-3770 32GB-RAM
Thanks,
CBruce
Hi Bruce,
I am also using Windows 10 but unfortunately I am not getting the GPF on File/Open of a .bas file using x64 version of WinFBE.
Does it happen for you fore every *.bas file that you try to open, or just for a specific file? If just for one specific file then maybe it is the internal WinFBE parser that is GPF'ing when trying to parse the code for that file.
The author, David Roberts, mentioned the SetCompilerPathsII issue to me a few days ago. That tool is no longer applicable in WinFBE 3 so it has been removed from the distribution, however, an entry for it was still be generated for new default winfbe.ini configuration file.
One file, multiple files, different file types, and even drag and drop a file... bites the dust each time.
And, like I said, the x32 version is not a problem at all.
I am also using Windows 10, not getting the GPF Bruce is getting on File/Open of a .bas, .bi, or .inc files using x64 version of WinFBE 3 Beta 2.
My File/Open File... dialog has an "Open" button, not an "OK" button.
Thanks Clive for the report. Appreciate it.
Bruce, could you download and replace your existing WinFBE64.exe with the one int he following zip file? Please let me know if it makes any difference at all.
https://www.planetsquires.com/files/WinFBE64.zip (https://www.planetsquires.com/files/WinFBE64.zip)
Nope, Paul. Same problem.
FYI, Paul... Windows event log ERROR and INFO entries for the crash - (from the special build you had me download)... standard "trying to run something at location 0x0":
Faulting application name: WinFBE64.exe, version: 0.0.0.0, time stamp: 0x62522431
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x0000000000000000
Faulting process id: 0x20bc
Faulting application start time: 0x01d84c810f45d7ea
Faulting application path: D:\FB_WinFBE_3_BETA_2\WinFBE64.exe
Faulting module path: unknown
Report Id: 513dc229-3b02-4f47-a6b7-592cdb096ae8
Faulting package full name:
Faulting package-relative application ID:
Fault bucket 2166815065118652559, type 5
Event Name: BEX64
Response: Not available
Cab Id: 0
Problem signature:
P1: WinFBE64.exe
P2: 0.0.0.0
P3: 62522431
P4: StackHash_58b2
P5: 0.0.0.0
P6: 00000000
P7: PCH_84_FROM_WinFBE64+0x0000000000040F68
P8: c0000005
P9: 0000000000000008
P10:
Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA3FE.tmp.dmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA48C.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA49C.tmp.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA4AC.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA4BC.tmp.txt
These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_WinFBE64.exe_d55c7d4a648fb28396214c65911327b5c4fc478a_3e590e1a_0fdea72a
Analysis symbol:
Rechecking for solution: 0
Report Id: 513dc229-3b02-4f47-a6b7-592cdb096ae8
Report Status: 268435456
Hashed bucket: ae091e442d1273c86e1212d24a5cb88f
Cab Guid: 0
Thanks Bruce, this might be a tough error for me to track down but I will do some detective work and I'll post back here when I think I've isolated the issue.
Hi Bruce,
I am pretty sure that I found the source of the GPF. The top tab control current tab selected was set to -1 but there was an array that needed to be accessed in order to position the tab correctly. The -1 would cause an invalid array access.
Please try the following new EXE to see if the problem is now fixed.
https://www.planetsquires.com/files/WinFBE64-fix.zip (https://www.planetsquires.com/files/WinFBE64-fix.zip)
Thanks,
Paul
Sorry, Paul. Same problem still.
Well, that is odd. I compiled the 64 bit using -exx in order to get the out of bound exceptions. Sure enough, when I ran the program and tried to display a new or existing file then the program would GPF. After adding code to check for the out of bounds array index then the GPF vanished.
For the sake of completeness, can you check the file date/time o f the WinFBE64.exe that you are using to give me peace of mind that we are dealing with the same EXE's?
2022-04-10 12:41PM
Also, your program GPF's the very moment that select File/New or when you press Open to open an existing file? You don't see any tab loading at the top of the editor at all?
2022-04-10 12:41
2.03 MB (2,138,624 bytes)
After I do a [File][New] - there is a very short pause - (no tab appears) - then GPFs.
After I do a [File][Open] I get the open dialog - choose a file - hit [Open] - there is a very short pause - (no tab appears) - then GPFs.
Thanks, I'll do more investigation.... :-)
Ok, Paul. I have been compiling the BETA and shoving OutputDebugString() calls all through it.
Finally have narrowed it down to frmMain_OpenFileSafely().
It's good up until the call to pDoc->CreateCodeWindow( HWnd, false, bIsTemplate, wszName )... it dies in there somewhere.
I'll try to dig deeper.
CBruce
Hi Bruce,
That is where my journey started yesterday when I was tracing the GPF. I was able to follow out of that call and all the way to the function "frmTopTabs_PositionWindows" located in the frmTopTabs.inc file. In my case, the GPF was the result of gTTabCtl.CurSel being a value of -1 causing invalid array access.
This is the code that I added around the line 182 area:
if gTTabCtl.CurSel = -1 then
' Put If check for CurSel being invalid otherwise other tab calculations
' Scenarios will fail via GPF on invalid array access.
' SCENARIO #1
' New gTTabCtl.CurSel is located before gTTabCtl.FirstDisplayTab so it is visually
' not on screen. We simply need to move the gTTabCtl.CurSel rect into the
' the first position (gTTabCtl.FirstDisplayTab) and adjust all rects accordingly.
elseif gTTabCtl.CurSel < gTTabCtl.FirstDisplayTab then
' The amount of the adjustment is equal to the difference between the
' current first tab's left edge and the new cursel's left edge.
...
...
Paul, it does a GPF on the first SciMsg() call in CreateCodeWindow().
' Disable scintilla vertical scroll bar (wParam = 1 to enable)
SciMsg( m_pSci(0), SCI_SETVSCROLLBAR, 0, 0 ) '' <=== dies here.
SciMsg( m_pSci(0), SCI_SETHSCROLLBAR, 0, 0 )
SciMsg( m_pSci(1), SCI_SETVSCROLLBAR, 0, 0 )
SciMsg( m_pSci(1), SCI_SETHSCROLLBAR, 0, 0 )
CBruce
Hi Bruce,
Thanks for the report, so if you comment out those lines then you are able to run the program and load files without any GPF's? If yes, then I can easily fix this problem.
Thanks,
Paul
Maybe you can try the following code. Just comment out the SciMsg calls and replace them with SciExec calls after the document pointer to the split window is set.
' Disable scintilla vertical scroll bar (wParam = 1 to enable)
' SciMsg( m_pSci(0), SCI_SETVSCROLLBAR, 0, 0 )
' SciMsg( m_pSci(0), SCI_SETHSCROLLBAR, 0, 0 )
' SciMsg( m_pSci(1), SCI_SETVSCROLLBAR, 0, 0 )
' SciMsg( m_pSci(1), SCI_SETHSCROLLBAR, 0, 0 )
' Get the document pointer from our main control and assign it to the other split windows
dim as any ptr pDoc = cast(any ptr, SciMsg(m_pSci(0), SCI_GETDOCPOINTER, 0, 0))
if pDoc then SciMsg( m_pSci(1), SCI_SETDOCPOINTER, 0, cast(LPARAM, pDoc))
SciExec( this.hWindow(0), SCI_SETVSCROLLBAR, 0, 0 )
SciExec( this.hWindow(0), SCI_SETHSCROLLBAR, 0, 0 )
SciExec( this.hWindow(1), SCI_SETVSCROLLBAR, 0, 0 )
SciExec( this.hWindow(1), SCI_SETHSCROLLBAR, 0, 0 )
See if that makes a difference for you. I am not getting any GPF's on my machine.
Thanks,
Paul
Paul, when I replace the "Disable" SciMsg() calls with the SciExec() calls, I get past the SciExec() calls with no problem... BUT...
Still get an access violation GPF on the first SciMsg() call:
' Get the document pointer from our main control and assign it to the other split windows
dim as any ptr pDoc = cast(any ptr, SciMsg(m_pSci(0), SCI_GETDOCPOINTER, 0, 0))
... whether that is before or after SciExec() calls.
NOTE:
I see some internet references to Scintilla access violations due to data structures being incorrect for x64 platforms. Perhaps that is related.
Possible data corruption(Plugin Failure) in x64 environment due to usage of int where intptr_t should have been used
https://github.com/kbilsted/NotepadPlusPlusPluginPack.Net/issues/74
[x64 fix]: Scintilla structures required correction for x64
https://github.com/kbilsted/NotepadPlusPlusPluginPack.Net/pull/75
Thanks Bruce, so it appears that the direct function pointers returned from the SCI_GETDIRECTPOINTER must be invalid. SciMsg is used a lot throughout the source code so we'll need to find the source of the problem, otherwise I will have to change all SciMsg with SciExec.
' Call the direct function for speed purposes rather than relying on the traditional SendMessage method.
m_pSci(i) = cast(any ptr, SendMessage( this.hWindow(i), SCI_GETDIRECTPOINTER, 0, 0 ))
Can you output debug what the values are for the above variable m_pSci(i). Is it zero? Maybe it is some random number that is not actually a function pointer. Every document loaded or created in WinFBE will have 2 Scintilla windows associated with it. One is the main editing window and the other is the split editing window. The array variables m_pSci(0) and m_pSci(1) simply hold the pointers to the direct function call handler within Scintilla.
You may be right about the 64 bit alignment issue. I remember early in WinFBE development that there was some alignment issues that needed to be taken care of with regards to the Notification structure. Their might be more now.
Paul, here's the debug output and my instrumented code for the first part of CreateCodeWindow().
The m_pSci() elements are = 0 when we get to the SciMsg() calls.
But the m_pSci() elements are never set at the beginning of CreateCodeWindow(). We never get inside the "if IsWindow(this.hWindow(i)) then" to set them.
[11012] BEH says: ONCOMMAND_FILEOPEN :: Before: pDoc = frmMain_OpenFileSafely(HWnd, _
[11012] BEH says: FRMMAIN_OPENFILESAFELY :: Before: pDoc = gApp.AddNewDocument()
[11012] BEH says: FRMMAIN_OPENFILESAFELY :: After: pDoc = gApp.AddNewDocument()
[11012] BEH says: FRMMAIN_OPENFILESAFELY :: Before: wszName = OnCommand_FileAutoSaveFileCheck( wszName )
[11012] BEH says: FRMMAIN_OPENFILESAFELY :: After: wszName = OnCommand_FileAutoSaveFileCheck( wszName )
[11012] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: 1
[11012] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: 2
[11012] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: 3
[11012] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: 4
[11012] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: 2
[11012] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: 3
[11012] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: 4
[11012] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: 12
[11012] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: m_pSci(0) = 0
[11012] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: m_pSci(1) = 0
function clsDocument.CreateCodeWindow( _
byval hWndParent as HWnd, _
byval IsNewFile as boolean, _
byval IsTemplate as boolean = false, _
byref wszFile as wstring = "" _
) as HWnd
dim ibeh as integer = 0
beh(__function__ + " :: " + str(1))
' Creates a Scintilla editing window (initially not visible). Optionally, load a diskfile
' into the window and apply properties to it.
for i as long = lbound(this.hWindow) to ubound(this.hWindow)
beh(__function__ + " :: " + str(2))
this.hWindow(i) = CreateWindowEx( 0, "Scintilla", "", _
WS_CHILD or WS_TABSTOP or WS_CLIPCHILDREN, _
0,0,0,0,hWndParent, _
cast(HMENU, IDC_SCINTILLA+i), GetModuleHandle(null), null)
beh(__function__ + " :: " + str(3))
SendMessage( this.hWindow(i), SCI_SETMODEVENTMASK, _
SC_MOD_INSERTTEXT or SC_MOD_DELETETEXT, 0 )
beh(__function__ + " :: " + str(4))
' Initialize our direct access to the Scintilla code windows. This is much faster than
' using SendMessage to the window. Only need to initialize once no matter how many
' code windows that are eventually opened.
if IsWindow(this.hWindow(i)) then
beh(__function__ + " :: " + "INSIDE 'if IsWindow(this.hWindow(i))' and i = " + str(i)) '' <<=== NEVER GET HERE
' NOTE: In my testing, need to only set the Scintilla lexer to the base editing
' window only and NOT both split windows. Also need to do this immediately after
' the window is created and do not send the message again afterwards.
' Also, every window must have a separate new call to CreateLexer. We can not
' just get one lexer and then try to share it amongst multiple new windows. When
' a window is destroyed then the pointer would be as well causing other existing
' windows to GPF.
if i = 0 then
' Load the FB lexer from Lexilla and feed it into Scintilla
beh(__function__ + " :: " + str(5))
dim as any ptr pLexer = gApp.pfnCreateLexerfn( "winfbe" )
beh(__function__ + " :: " + str(6))
SendMessage( this.hWindow(i), SCI_SETILEXER, 0, cast(LPARAM, pLexer) )
beh(__function__ + " :: " + str(7))
end if
if SciMsg = 0 then
beh(__function__ + " :: " + str(8))
SciMsg = cast( Scintilla_Directfunction, SendMessage( this.hWindow(0), SCI_GETDIRECTFUNCTION, 0, 0 ) )
beh(__function__ + " :: " + str(9))
end if
' Call the direct function for speed purposes rather than relying on the traditional SendMessage method.
beh(__function__ + " :: " + str(10))
m_pSci(i) = cast(any ptr, SendMessage( this.hWindow(i), SCI_GETDIRECTPOINTER, 0, 0 )) '' <<=== SO THESE DON'T GET SET
beh(__function__ + " :: " + str(11))
end if
next
ibeh = 11
' Disable scintilla vertical scroll bar (wParam = 1 to enable)
' SciMsg( m_pSci(0), SCI_SETVSCROLLBAR, 0, 0 )
' SciMsg( m_pSci(0), SCI_SETHSCROLLBAR, 0, 0 )
' SciMsg( m_pSci(1), SCI_SETVSCROLLBAR, 0, 0 )
' SciMsg( m_pSci(1), SCI_SETHSCROLLBAR, 0, 0 )
' Get the document pointer from our main control and assign it to the other split windows
' dim as any ptr pDoc = cast(any ptr, SciMsg(m_pSci(0), SCI_GETDOCPOINTER, 0, 0))
' if pDoc then SciMsg( m_pSci(1), SCI_SETDOCPOINTER, 0, cast(LPARAM, pDoc))
' Disable scintilla vertical scroll bar (wParam = 1 to enable)
SciExec( this.hWindow(0), SCI_SETVSCROLLBAR, 0, 0 )
SciExec( this.hWindow(0), SCI_SETHSCROLLBAR, 0, 0 )
SciExec( this.hWindow(1), SCI_SETVSCROLLBAR, 0, 0 )
SciExec( this.hWindow(1), SCI_SETHSCROLLBAR, 0, 0 )
' Get the document pointer from our main control and assign it to the other split windows
ibeh += 1 : beh(__function__ + " :: " + str(ibeh)) '' <<=== # 12
beh(__function__ + " :: " + "m_pSci(0) = " + str(m_pSci(0)))
beh(__function__ + " :: " + "m_pSci(1) = " + str(m_pSci(1)))
dim as any ptr pDoc = cast(any ptr, SciMsg(m_pSci(0), SCI_GETDOCPOINTER, 0, 0))
ibeh += 1 : beh(__function__ + " :: " + str(ibeh))
if pDoc then SciMsg( m_pSci(1), SCI_SETDOCPOINTER, 0, cast(LPARAM, pDoc))
ibeh += 1 : beh(__function__ + " :: " + str(ibeh))
NOTE: beh() is just a wrapper for OutputDebugString()...
' ------------------------------------------------------------
' ------------------------------------------------------------
declare sub beh(sstr as string)
' ------------------------------------------------------------
' BEH()
' ------------------------------------------------------------
#include once "windows.bi"
sub beh(sstr as string)
sstr = "BEH says: " + sstr + chr(13) + chr(10)
OutputDebugString(sstr)
end sub
Added a couple of more debugs to verify variables used when calling CreateCodeWindow()...
pDoc gets set via gApp.AddNewDocument().
And wszName got set by the file picker.
But CREATEWINDOWEX() appears to be failing in CreateCodeWindow()! this.hWindow(i) = 0 after each call!
EDITED with debugs to show that the hWnd is getting passed properly to CreateCodeWindow().
EDITED AGAIN to show GETLASTERROR() = 1407 after CREATEWINDOWEX()
Microsoft says:
ERROR_CANNOT_FIND_WND_CLASS
1407 (0x57F)
Cannot find window class.
[16416] BEH says: ONCOMMAND_FILEOPEN :: pDoc = 0
[16416] BEH says: ONCOMMAND_FILEOPEN :: pDocIn = 0
[16416] BEH says: ONCOMMAND_FILEOPEN :: pDoc = 0
[16416] BEH says: ONCOMMAND_FILEOPEN :: pDocIn = 0
[16416] BEH says: ONCOMMAND_FILEOPEN :: Before: pDoc = frmMain_OpenFileSafely(HWnd, _
[16416] BEH says: FRMMAIN_OPENFILESAFELY :: Before: pDoc = gApp.AddNewDocument()
[16416] BEH says: FRMMAIN_OPENFILESAFELY :: pDoc = 0
[16416] BEH says: FRMMAIN_OPENFILESAFELY :: pDocIn = 0
[16416] BEH says: FRMMAIN_OPENFILESAFELY :: After: pDoc = gApp.AddNewDocument()
[16416] BEH says: FRMMAIN_OPENFILESAFELY :: pDoc = 47886208
[16416] BEH says: FRMMAIN_OPENFILESAFELY :: pDocIn = 0
[16416] BEH says: FRMMAIN_OPENFILESAFELY :: Before: wszName = OnCommand_FileAutoSaveFileCheck( wszName )
[16416] BEH says: FRMMAIN_OPENFILESAFELY :: wszName = D:\FreeBASICx64\00_BRUCE\WinFBE-master\Examples\CADODB\EX_CADO_Command_Execute.bas
[16416] BEH says: FRMMAIN_OPENFILESAFELY :: After: wszName = OnCommand_FileAutoSaveFileCheck( wszName )
[16416] BEH says: FRMMAIN_OPENFILESAFELY :: wszName = D:\FreeBASICx64\00_BRUCE\WinFBE-master\Examples\CADODB\EX_CADO_Command_Execute.bas
[16416] BEH says: FRMMAIN_OPENFILESAFELY :: Before: pDoc->CreateCodeWindow( HWnd, false, bIsTemplate, wszName )
[16416] BEH says: FRMMAIN_OPENFILESAFELY :: hWnd = 3675218
[16416] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: 1
[16416] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: hWndParent = 3675218
[16416] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: 2
[16416] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: behLastError = 1407
[16416] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: this.hWindow(i) = 0 :: i = 0
[16416] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: 3
[16416] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: 4
[16416] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: 2
[16416] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: behLastError = 1407
[16416] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: this.hWindow(i) = 0 :: i = 1
[16416] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: 3
[16416] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: 4
[16416] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: 12
[16416] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: m_pSci(0) = 0
[16416] BEH says: CLSDOCUMENT.CREATECODEWINDOW :: m_pSci(1) = 0
Referring to the 1407 error in my post above... I don't see a LoadLibrary() call for the Scintilla DLL anywhere in the WinFBE source code.
CBruce
EDIT: Oops! I just discovered FB's DYLIBLOAD().
The LoadLibrary code is located in the "WinFBE.bas" main file. I am using FB's DyLibLoad which is just simply a wrapper around the Windows API call to LoadLibrary.
#IfDef __FB_64BIT__
' Load the Scintilla code editing dll
dim as any ptr pLibLexilla = dylibload("Lexilla64.dll")
dim as any ptr pLibScintilla = dylibload("Scintilla64.dll")
#Else
' Load the Scintilla code editing dll
dim as any ptr pLibLexilla = dylibload("Lexilla32.dll")
dim as any ptr pLibScintilla = dylibload("Scintilla32.dll")
#EndIf
gApp.pfnCreateLexerfn = cast(CreateLexerFn , GetProcAddress(pLibLexilla, "CreateLexer"))
You do have Scintilla64.dll and Lexilla64.dll in the same folder as your WinFBE64.exe ?
Yep... everything is as originally unzipped.
Quote from: Bruce Huber on April 12, 2022, 07:43:36 PM
Yep... everything is as originally unzipped.
Interesting. Does the pLibScintilla variable return a value, or just zero?
That's what I was thinking too...
[13256] BEH says: WINMAIN :: pLibLexilla = 0
[13256] BEH says: WINMAIN :: pLibScintilla = 0
Hmmmm... interesting that it is not loading the DLL. I don't know the reason yet because it loads on my machine. Odd.
Asa complete aside, I don't need to use OutputDebugString because I compile using the build "Win32 Console (Release)" which allows a console window to display when WinFBE runs. This allows me to sprinkle "?" print statements in the code. I just need to remember to go back and delete those "?" print statements when they are no longer needed.
Paul, can I replace the Scintilla DYLIBLOAD/FREE with LoadLibrary/Free to see if there is an issue there? Or is DYLIB* giving you additional functionality?
FYI: I like OutputDebugStr() because it doesn't slow down the app even when I'm shoveling out data like crazy. I use a little wrapper (in the code a coupe of posts back) with some short name to make it easy to type, and that also allows me to do things like automatically add a CRLF to the end of the output string so that it auto flushes the output buffer and I can watch in real time in DebugView from SysInternals. (I usually implement it as a little macro so I can easily disable it completely).
Hi Bruce, yes you should be able to substitute Loadlibrary/Freelibrary. Hope making that change actually fixes the problem! :-)
:(
No difference.
That is unfortunate.
I have attached two very simple console programs that simply load the scintilla(32/64).dll and lexilla(32/64).dll and report the pointer values. The source code is also provided.
I encourage people here that read this post to download it and test on your computers to see if the 64 bit version fails to load the DLL's and return zero values for the pointers.
Simply unzip the attachment to an empty folder. Open a Windows terminal in that folder and run these two programs:
./dll_test32.exe
./dll_test64.exe
I would be very interested to hear of others get zero values on their Windows 64 bit systems.
Thanks
Paul
WinFBE BETA 3 x64 is still doing an access violation GPF... but... I will get back to debugging it more in a little while after I tell you about getting past loading the scintilla DLLs.
I ran Dependencies against the scintilla DLLs and found that my system was missing VCRUNTIME140_1.dll. After I updated the VC rtlibs, the scintilla DLLs load and give me good pointers - (but it still GPFs later).
Dependencies - An open-source modern Dependency Walker
https://github.com/lucasg/Dependencies
Microsoft Visual C++ Redistributable latest supported downloads
Visual Studio 2015, 2017, 2019, and 2022
https://docs.microsoft.com/en-US/cpp/windows/latest-supported-vc-redist?view=msvc-170
(Back to debugging...)
Paul, the programs work ok but windows defender is suspicious and wants me to do a cloud security scan
Yay!!! Went back to original source, now that Scintilla.dll resolves, (in case I added a bug while debugging) - compiled - and it runs WONDERFULLY WELL!!!
Thanks a LOT for the help, Paul!!!
CBruce
Hello Paul
For me, no zero values are returned in either program.
I have tested it on different PC's with Windows 10 and 11.
Even with windows 11 under VirtualBox on a macOS computer it works. :-)
Quote from: Bruce Huber on April 12, 2022, 11:18:08 PM
Yay!!! Went back to original source, now that Scintilla.dll resolves, (in case I added a bug while debugging) - compiled - and it runs WONDERFULLY WELL!!!
Thanks a LOT for the help, Paul!!!
CBruce
This is fantastic news! Looks like we can put this bug behind us now.
I will package up a BETA 3 and release it just so that we can all test a version before I send out the final Version 3 to the world at large.
Thanks Joerg and Johan for testing the sample program - I appreciate it.
Hello Paul,
maybe you're still working on it, but I can't open or save projects with 64 bits version, Winfbe crashes.
Opening a single file works.
starting WinFBE64 with administrator rights; the file menu looks crippled.
Hi Paul, FYI, my Windows 10 Pro machine opens projects and files in both 32bit and 64bit WinFBE versions without issues. (Older Dell 9010 with lots of HDD space and RAM.)
Hi guys, yes, there is an array access error that could result in GPF. That was fixed. I will release a BEAT 3 asap so that we can ll be working from a common code base.