Running 3.20a (c02f2513f) on Windows 10 32-bit.
For the last week I've gotten several appcrashes whenever sbbsctrl.exe starts up.
Faulting application name: sbbsctrl.exe, version: 3.20.0.0, time stamp: 0x00000000
Faulting module name: gdi32full.dll, version: 10.0.19041.2604, time stamp: 0x2b5302d5
Exception code: 0xc0000090
Fault offset: 0x0003f8e5
Faulting process id: 0x1f80
Faulting application start time: 0x01d952d887c053d6
Faulting application path: C:\sbbs\exec\sbbsctrl.exe
Faulting module path: C:\Windows\System32\gdi32full.dll
Report Id: 74424471-cef3-489d-ac6d-ab7ca4b0be51
Faulting package full name: (blank)
Faulting package-relative application ID: (blank)
It first happened this past Sunday evening after I stopped and restarted the Mail service, and I couldn't get sbbsctrl.exe to start at all until I re-installed Synchronet from scratch and copied the data to the new install. Today it started happening again (the one pasted above is from today) after a reboot of the PC. Every appcrash message lists the faulting module as gdi32full.dll.
I don't want to have to go through a whole install again, so at the moment I'm just using sbbs.exe to run the BBS in place of sbbsctrl.exe. Nice to have as a backup option, but I miss sbbsctrl.exe :)
Happy to provide more detail if I can.
Try deleting or renaming the Windows registry key that contains the sbbsctrl settings: http://wiki.synchro.net/monitor:sbbsctrl#settings and see if that helps.
I certainly can't think of any recent changes that would cause GDI-related crashes and I haven't seen them myself or heard any other reports of them. --
Re: sbbsctrl.exe APPCRASH (gdi32full.dll)
By: Digital Man to Codefenix on Thu Mar 09 2023 06:06 pm
Try deleting or renaming the Windows registry key that contains the sbbsctrl settings: http://wiki.synchro.net/monitor:sbbsctrl#settings and see if that helps.
Ok, I renamed the "Synchronet Control Panel" entry to "Synchronet Control Panel - OLD" and reran sbbsctrl.exe. A new blank entry for Control Panel showed up in the registry, but unfortunately I get the same outcome as before.
I tried setting some Autostart properties to false in ctrl/sbbs.ini today, specifically Mail and BBS. With those not starting on their own, sbbsctrl.exe does not immediately crash. But if I manually start up either the Mail or Termainal Server by hitting either one's play button, then sbbsctrl.exe crashes with the message in the event viewer.
I certainly can't think of any recent changes that would cause GDI-related crashes and I haven't seen them myself or heard any other reports of them. --
Starting to wonder if it's a red herring. Just for the heck of it, I made sure Windows was up to date. The Intel driver did need an update, but since updating it hasn't made a difference for this issue I'm having.
You might try install a fresh copy of sbbs (not using the setup.exe) into a separate folder with all stock configuration files and see if that makes any difference. If you have another computer or VM you could try to reproduce the problem on, that'd be helpful to know too.
DM, if you'd like, I can send you both my good and bad file.ini for comparison.
Yes, please!
Re: sbbsctrl.exe APPCRASH
By: Digital Man to Codefenix on Sat Mar 11 2023 02:53 pm
Yes, please!
Sent.
I narrowed it down (quickly) to the min_dspace setting. Yours was set to 16384P (petabytes), which exceeds the value that can be stored in a 64-bit (signed) integer and that appears to do something weird when called that code was called from sbbsctrl.exe that caused all subsequent floating point operations to cause a "invalid operation" floating point exception. I added some code to force that value within the range of a 64-bit integer, but it's still kind of mysterious why that happens, and only with sbbsctrl.exe.
Did you intentionally change the min disk space setting to that (very high) value or is that also a mystery? :-)
Yeah, I noticed the 16384P as well and wondered if that had something to do with the problem.
Did you intentionally change the min disk space setting to that (very high) value or is that also a mystery? :-)
No, I have no idea how it got set that high. Definitely didn't change that value intentionally.
Any chance that it could have gotten changed between iterations of 3.20a? If
I missed a jsexec update between builds, could that cause a corrupted ini?
Sysop: | altere |
---|---|
Location: | Houston, TX |
Users: | 66 |
Nodes: | 4 (0 / 4) |
Uptime: | 16:54:57 |
Calls: | 728 |
Files: | 7,667 |
Messages: | 292,779 |