Hi Jack,

We needed to change the IP address for users at a company for a switch over.

The following has affected about half their PCs and some but not all the Windows logins on a remote desktop server.

When trying to use the atecfg dialog I pressed the Configure button and the Configure dialog pops up with no details in it apart from a login time then disappears after a tiny bit of blue circle cursor (maybe 1 sec). There is an app crash (below) in Event Viewer. This is Windows 10 different PCs mostly but not all at the latest Windows 10.

I put on my Bodger McBogerson hat and managed to get an interim solution by directly importing a registry tree myself. This worked but of course they can't make any changes to it.

Things I tried:

Full uninstall, delete manually all the registry entries. Re-install. Exactly the same problem.
The registry entries that I deleted were in the SOFTWARE/Wow3264Node/Microsabio. I bodged in mine to just SOFTWARE/Microsabio
Running as Admin,not admin, Local Admin with no difference.
Hunted through the other profiles on the PC and got rid of all Microsabio entries.
Changed the permissions on C:\ATE to full access for everyone (and the User)

ashlog.log on the PC just shows the atecfg dialog starting but then nothing as it crashes.

Any ideas?

Dominic


Sample Appcrash:
Faulting application name: ashw32.exe, version: 6.5.1673.0, time stamp: 0x5df86b62 <-------tried slightly older and new versions up to 1691.2 but no difference.
Faulting module name: ashw32.exe, version: 6.5.1673.0, time stamp: 0x5df86b62
Exception code: 0xc0000005
Fault offset: 0x000715d8
Faulting process ID: 0x1f6c
Faulting application start time: 0x01d87e6145b9f2b1
Faulting application path: C:\ATE\bin\ashw32.exe
Faulting module path: C:\ATE\bin\ashw32.exe
Report ID: 7ca4bdbc-4ceb-4642-95c2-13f0b5b0246a
Faulting package full name:
Faulting package-relative application ID:

I'm not aware of this problem having affected anyone else, and don't have any great ideas yet of what the issue is. But I do have an idea for how to gather more information and possibly pinpoint where the offending operation is (probably a call into a Windows DLL function)...

Edit your C:\ATE\MIAME.INI file and add TRACE=GUI,XCALL,XDEBUG

At least then your C:\ATE\ASHLOG.LOG file should log all of the XCALLs and GUI control creation operations leading up to the crash, which hopefully will produce something like a smoking gun.

Thanks Jack. I still have a few PCs to bodge, so I will do this first

I have attached a log from the Configure box disappearing. It is pretty long!

Dom

Hi Bodger,

That was actually very helpful. And fortunately, unlike in the old days where you had to sit through the entire movie to find out who done it, here we can just skip to the end of the log file. The crash occurs within WINPTRLST.SBX, called by ATECFX.SBX, called by TELNET.LIT. WINPTRLST.SBX uses DYNLIB to enumerate available printers using a function EnumPrinters() which is exposed within the Windows dynamic library module WINSPOOL.DRV. The actual point of failure is a call into a DYNLIB utility function to dereference a raw memory pointer returned by the EnumPrinters() function...



The first line is the call into EnumPrinters(). The second line is a trace of the trace message indicating that it found 11 printers. It then proceeds through the array of printers, converting the structure returned by EnumPrinters (an array of pointers to actual printer names) into a more traditional array of strings. The last line is the attempt to copy the string at memory location 26928340 into an S64 string variable, and that's where it crashes.

So we know who done it, but still don't understand the motivation, i.e. is the memory location returned by EnumPrinters invalid? Or is the DYNLIB utility function to dereference failing for some other reason? And why is is just showing up now in this one environment?

I propose a the following steps to further the investigation:

1) Since there have been some refinements to the DYNLIB subroutine recently, I suggest you start with updating your ATE to the 6.5.1717.3 using ate-6.5.1717.3-web-upd.exe (also accessible via Help > Check For Updates from within ATE). If that doesn't just solve it, then...

2) Let's focus on WINPTRLST.SBX, which may be easier to debug from a standard A-Shell/Windows session rather than ATE. (But I recommend you update your A-Shell windows to match, either using the ashw32.exe from ATE or from this link: ash-6.5.1717.4-w32c-upd.zip. Then log to [907,29] within your SOSLIB area (or just create the ppn) and populate it with the test program winptrtst.run and winptrlst.sbx. (This version of WINPTRLST.SBX is slightly newer than the version released with ATE, but only to add a bit more tracing.) SET DEBUG and SET TRACE XCALL ON and SET TRACE XDEBUG ON and then RUN WINPTRTST (hit ENTER to accept the default option) and let's see if that works. If that works, we might try swapping the two versions of WINPTRLST.SBX to see if it's something about the compilation or about ATE vs A-Shell/Windows.

3) If that doesn't solve the crime,then let's take a closer look your WINSPOOL.DRV. I'm assuming that the version that gets loaded is from c:\Windows\SysWOW64, in which case mine is dated 11-May-22 and is 435K. (Oddly, no version is included.) If your is different, maybe send it over?

Result of test using "Local Session" in ATE, as suggested by Mr Evans. As I have to test it on the customer's PC, trying to do minimum harm initially.

Fn'MinAshVer(6,3,1526,0,0): ash: 6,5,1692,1 ate: 0,0,0,0 = 2016601
MATCH: 5, I=1, A2S[A2;I]=T,A2S[A2+I;1]=R
MATCH: 1, I=2, A2S[A2;I]=TR,A2S[A2+I;1]=A
MATCH: 1, I=3, A2S[A2;I]=TRA,A2S[A2+I;1]=C
MATCH: 1, I=4, A2S[A2;I]=TRAC,A2S[A2+I;1]=E
MATCH: 1, I=5, A2S[A2;I]=TRACE,A2S[A2+I;1]=
Fn'MinAshVer(6,3,1526,0,0): ash: 6,5,1692,1 ate: 0,0,0,0 = 2016601
MATCH: 5, I=1, A2S[A2;I]=T,A2S[A2+I;1]=R
MATCH: 1, I=2, A2S[A2;I]=TR,A2S[A2+I;1]=A
MATCH: 1, I=3, A2S[A2;I]=TRA,A2S[A2+I;1]=C
MATCH: 1, I=4, A2S[A2;I]=TRAC,A2S[A2+I;1]=E
MATCH: 1, I=5, A2S[A2;I]=TRACE,A2S[A2+I;1]=
Fn'MinAshVer(6,3,1526,0,0): ash: 6,5,1692,1 ate: 0,0,0,0 = 2016601
MATCH: 5, I=1, A2S[A2;I]=T,A2S[A2+I;1]=R
MATCH: 1, I=2, A2S[A2;I]=TR,A2S[A2+I;1]=A
MATCH: 1, I=3, A2S[A2;I]=TRA,A2S[A2+I;1]=C
MATCH: 1, I=4, A2S[A2;I]=TRAC,A2S[A2+I;1]=E
MATCH: 1, I=5, A2S[A2;I]=TRACE,A2S[A2+I;1]=
(XCALL mode) flags=6,level=4, name=
guiflags = 12A1
(Local windows/server mode)
Initial call to EnumPrintersA to get required buffer size...
Required size: 1080
Second call to EnumPrintersA with required buffer to get actual printer info...
Printer structures allocated: 91
EnumPrintersA() flags=6, level=4, name=
pcreturned = 12
i=[1], p4(i).pPrinterName=[21608638], p4(i).Attributes=[4194368]
pname=OneNote for Windows 10, server=
i=[2], p4(i).pPrinterName=[21608602], p4(i).Attributes=[576]
pname=OneNote (Desktop), server=
i=[3], p4(i).pPrinterName=[21608542], p4(i).Attributes=[576]
pname=Microsoft XPS Document Writer, server=
i=[4], p4(i).pPrinterName=[21608496], p4(i).Attributes=[576]
pname=Microsoft Print to PDF, server=
i=[5], p4(i).pPrinterName=[21608488], p4(i).Attributes=[16448]
pname=Fax, server=
i=[6], p4(i).pPrinterName=[21608404], p4(i).Attributes=[10776]
pname=\\RDSDC\Canon MF8500C Series UFRII LT XPS, server=\\RDSDC
i=[7], p4(i).pPrinterName=[21608330], p4(i).Attributes=[10776]
pname=\\RDSDC\Samsung M283x Madics, server=\\RDSDC
i=[8], p4(i).pPrinterName=[21608260], p4(i).Attributes=[10776]
pname=\\rdsdc\Main Office Copier, server=\\rdsdc
i=[9], p4(i).pPrinterName=[21608136], p4(i).Attributes=[10776]
pname=\\RDSDC\HP Laserjet 2605dn (Universal Printing PCL 6), server=\\RDSDC
i=[10], p4(i).pPrinterName=[21608076], p4(i).Attributes=[10776]
pname=\\RDSDC\Samsung M283x, server=\\RDSDC
i=[11], p4(i).pPrinterName=[21608000], p4(i).Attributes=[536]
pname=\\RDSDC\TOSHIBA e-STUDIO389CS, server=\\RDSDC
i=[12], p4(i).pPrinterName=[21607910], p4(i).Attributes=[8728]
pname=\\RDSDC\HP Color LaserJet 3700 PCL 5, server=\\RDSDC
returning status=12

The bottom of the Trace log as before from this PC (I had to get on one where the person had gone home):

14-Jun-22 17:11:50 [RDS-PC08:01-0]<TELNET:WINPTRLST:e6a> xcall EVTWIN,F8[258],S60[Initial call to EnumPrintersA to get requi...]
14-Jun-22 17:11:50 [RDS-PC08:01-0]<TELNET:WINPTRLST:eb7> xcall DYNLIB,X84,S23[EnumPrintersA(IVIpIpp)i],B4[6],S64[],B4[0],X0,B4[0],B4[0],B4[0],I4[0]
14-Jun-22 17:11:50 [RDS-PC08:01-0]<TELNET:WINPTRLST:eec> xcall EVTWIN,F8[258],S18[Required size: 880]
14-Jun-22 17:11:50 [RDS-PC08:01-0]<TELNET:WINPTRLST:f10> xcall EVTWIN,F8[258],S79[Second call to EnumPrintersA with required...]
14-Jun-22 17:11:50 [RDS-PC08:01-0]<TELNET:WINPTRLST:1149> xcall EVTWIN,F8[258],S32[Printer structures allocated: 74]
14-Jun-22 17:11:50 [RDS-PC08:01-0]<TELNET:WINPTRLST:6b4> xcall MIAMEX,F8[7],F[0]
14-Jun-22 17:11:50 [RDS-PC08:01-0]<TELNET:WINPTRLST:6f2> xcall MIAMEX,F8[9],F8[6],B2[0],F8[132],S16[]
14-Jun-22 17:11:50 [RDS-PC08:01-0]<TELNET:WINPTRLST:11b5> xcall EVTWIN,F8[258],S39[EnumPrintersA() flags=6, level=4, name=]
14-Jun-22 17:11:50 [RDS-PC08:01-0]<TELNET:WINPTRLST:1200> xcall DYNLIB,X84,S23[EnumPrintersA(IVIpIpp)i],B4[6],S64[],B4[4],X12(),B4[880],B4[880],B4[74],I4[0]
14-Jun-22 17:11:50 [RDS-PC08:01-0]<TELNET:WINPTRLST:123c> xcall EVTWIN,F8[258],S15[pcreturned = 10]
14-Jun-22 17:11:50 [RDS-PC08:01-0]<TELNET:WINPTRLST:13d9> xcall DYNLIB,X84,B4[24052610],S64[]

So I removed 2 Offline printers from the PC an now the config dialog works!!!! I have run the tests again (attached). WINTSTPTR and ashlog now return the same number (10) rather than 10 and 12 printers so maybe there is something to that?

...
The odd thing about this is the crash seems to occur in the operation of dereferencing the pointer to the printer name in the structure returned by EnumWindows(). If it had something to do with the status of the printer, it seems like the problem would have occurred in the EnumWindows() call, rather than the conversion of the returned pointers to the printer names. The ashlog shows the pointer/address that it was crashing on (24052610), but unfortunately there is no easy way to determine whether that address was valid.

It's also interesting that the ATE Local Session test (good idea by Mr. Evans) didn't fail. (Am I right in assuming that this was on a PC that otherwise failed when trying to launch the configuration dialog?) In theory the two variations should have had essentially equal results, other than different memory locations in play.

Which two printers did you remove?

"Am I right in assuming that this was on a PC that otherwise failed when trying to launch the configuration dialog?" - You are correct.

Printers removed:
i=[12], p4(i).pPrinterName=[21607910], p4(i).Attributes=[8728]
pname=\\RDSDC\HP Color LaserJet 3700 PCL 5, server=\\RDSDC

i=[9], p4(i).pPrinterName=[21608136], p4(i).Attributes=[10776]
pname=\\RDSDC\HP Laserjet 2605dn (Universal Printing PCL 6), server=\\RDSDC

Hmm..., nothing jumps out about those two printer entries being a problem. The p4() structure returned by EnumWindows() is just this:

The address that failed (24052610) is right in line with others in the array that worked in the local test, so it doesn't seem rogue.

The fact that the error occurs on the very first array element (even though your apparent fix involves removing elements 9 and 12) seems to go along with the fact that the local test succeeded even though it had the environment and set of printers as the one that crashes, suggesting that it's some kind of lurking bug just waiting for a particular memory/printer/IP/something configuration to trigger. But since that WINPTRLST.SBX routine hadn't changed since 2017, the set of conditions must be somewhat rare.

If I could figure out how to reproduce it here, I could probably trap it in the VS debugger, but so far no luck with that.

Just thought I would let you know that removing the offline printers (the same printers of course as they were shared from their server) has now worked on all PCs that I had left to fix.

Well I don't understand why, but I guess this wouldn't be the first unsolved Windows mystery I've had to learn to live with.

A quick update to remind myself more than anything. A new PC was put in at the same company and the two offending printers were on it, but NOT showing offline. However, I still had to remove them to get ATE to work. I could add their direct network printers no problem.

Well the good news is that you are almost certainly in the lead for the longest unsolved bug competition. The bad news is that you can’t officially take the prize until the bug is fixed, and we don’t seem to be any closer to that.

The other good news is that no one else has reported it.

I’m out in Palm Springs for a couple of days; maybe I’ll get some kind of inspiration staring at the palm trees swaying in the breeze…