WinBatch Compiler (32 bit) works - Compiler (64 bit) seems not to work

[Mik Luciuk]

I am on a Windows 10 machine using WinBatch+Compiler 2019A.

When I start either the 32bit or the 64bit versions or the Compiler, I am presented with the "menu" window where the compiler wants the input for Source..., Options..., Target..., etc.

In the 32bit version, I can click on the "buttons" (all of them) and the compiler reacts as expected - If I click on the "Source..." button, the system presents me with a common dialog FileOpen window where I can "select" the WBT that I wish to compile. Perfect.

In the 64bit version, not all the "buttons" are reacting as expected - If I click on the "Source..." button, the system appears to attempt to show me the common dialog FileOpen window (it flashes up) and then the compiler immediately terminates (goes poof - no error messages - nothing). This behavior is what I'm experiencing for any "button" that tries to present the common dialog FileOpen window ("Select...", "Target..." and "Icon..."). 

It does not seem to matter how I invoke Compiler64 - either from Studio or from the WinBatch PopMenu. Both invocations react the same

If I leave the parameters as they are (what came from the .CMP file), Compiler64 appears to process through correctly and create the .exe I expect.

Is there a problem with 2019a or a problem with my circumstances (some obscure Windows 10 thing or did I install incorrectly or ???)

[td]

Which version of Window 10 are you using?  I can duplicate the problem in 1903 but not in an earlier version of Windows 10.

[stanl]

I have 1809 [if it helps] - how did you get 1903?

[td]

Generally and if your 1809 is up-to-date, you simply need to "Check for updates" manually.  Be forewarned that it may fix a few 1809 bugs but adds a few new ones.  This topic being the latest example. 

[jmburton2001]

I reported this issue last year. Unfortunately there was no solution at that time.

I found the following workaround by accident...

I create a 32 bit "cmp" file (with the 32 bit compiler) using 32 bit equivalents that I want in the 64 bit compile.

Then I copy the xxxxxx32.cmp file and rename it xxxxxx64.cmp and then open the 64 bit compiler. At that point I'm able to change anything in the 64 bit interface without its unexpected terminations.

This has worked flawlessly for me. YMMV...

[td]

I may be misunderstanding what you are saying but I believe your problem is different than the one reported by the OP.  Having a pre-existing .cmp file would not permit you to use the Windows file dialog in the compiler in this case.  It would just prevent you from needing to use the shell file dialog at all.   Also, Windows 1903 was not released until April of 2019 so it wasn't around a year ago and Windows 1903 is the only version of Windows that we have been able to reproduce this problem on.  Nor did we receive any reports of the problem form users running the previous version of Window 10 (1809).  That said, it is possible that it was a problem in some other version of Windows 10, fixed, and then Windows regressed.  Windows 10 has been and continues to be buggy enough that it is not too difficult to believe that that this could happen.

The problem is that it unusual happens in the context of the compiler but never in the context of WinBatch.   The behavior is the result of recursion causing a stack overflow in one of the Windows shell dlls.  Normally, something like this causes an exception error message generated by the OS.  But the Windows shell dll appears to be trapping the exception so that it cannot propagate and instead it just terminates the process.  The usual cause of unplanned recursion is stack corruption but the consistency of the bug works against that unless the corruption is occurring in the same dll as the runaway recursion.

[jmburton2001]

In the 64bit version, not all the "buttons" are reacting as expected - If I click on the "Source..." button, the system appears to attempt to show me the common dialog FileOpen window (it flashes up) and then the compiler immediately terminates (goes poof - no error messages - nothing). This behavior is what I'm experiencing for any "button" that tries to present the common dialog FileOpen window ("Select...", "Target..." and "Icon...").

It does not seem to matter how I invoke Compiler64 - either from Studio or from the WinBatch PopMenu. Both invocations react the same

Hi Tony!

What OP described here is the exact problem I experienced (and have been experiencing since) last year. Since there was no apparent solution at that time I simply poked around and tried various things until I found my workaround. It was either that or be relegated to 32 bit executables.

I don't know all the ins and outs of how the compiler works or the technical details of how it interacts with the operating system as you've explained. That stuff is way beyond my limited knowledge.

At the end of the day... I just wanted a 64 bit executable of my scripts. This workaround solved this problem for me so I thought I'd share my experience.

[Mik Luciuk]

Hey TD

Here's my OS info

OS Name - Microsoft Windows 10 Enterprise
Version - 10.0.17763 Build 17763

Sorry, but I do not understand the 4 digit things that have been thrown around - 1903 or 1809 or any other 4 digit thing.

Agreed, there are probably 2 or 3 good work arounds, but I would kinda like to get the Compiler64 working the way I expect it to.....

[td]

Window 10.0.17763 is Windows 10 1809.  The current version of Windows 10 is 1903.  The year+month Windows version is the one displayed by Settings->About in the "Settings" system utility that MSFT is pushing on users.

As it happens there is a way to address the latest problem and permit the compiler to operate using the system's file open dialog.  There is no way to tell if this solution applies to all cases as there is some possibility that there multiple causes of the issue.   

Intel's Rapid Storage Technology comes with a file called the OptaneShellExt.dll.  It is a shell extension that supposedly caches folders in memory when accessed using the Windows File Explorer shell.  When this shell extension is disabled using MSFT System Internal's handly autoruns.exe utility, the 64-bit compiler is consistently able to use the open file dialog.  In our testing, there was no detectable difference in performance when the extension is disabled but your mileage may vary.  Disabling Intel's shell extension does not appear to affect the rest of the functionality provided by Intel's Rapid Storage Technology either.

Intel updated their Intel's Rapid Storage Technology software because of bugs sometime early this year and that update appears on several of our systems running Windows 10 1903.  It is unclear if the previous version of this software had a similar problem or not.  We did not test that possibility.     

There isn't a change that can be made to the 64-bit compiler to address this issue short of removing the shell's open file dialogs from the 64-bit compiler.  For obvious reasons, we would prefer not to do that.

[Mik Luciuk]

Thanks TD

this does clear up some of my confusion.

I am not really clear on what you'd recommend, if you did have a preference..

1. Use a work around
2. Disable the shell extension
3. Get Intel's Rapid Storage Technology software upgrade

The work around I understand.
If I need to disable the shell extension, I am not sure what exactly to look for to disable it.
I've never gone out to Intel to get an upgrade, so I'm sure there will be questions in that arena as well.

Recommendations and or guidance welcome.....

[td]

My personal preference is to disable Intel's OptaneShellExt shell extension using MSFT's autoruns.exe utility.  A quick Web search will land you a link to the System Internals download site:

https://docs.microsoft.com/en-us/sysinternals/downloads/

Click on the Autoruns link, read the description if you are inclined and click the download button.  Unzip the compressed file to a folder of your choice.  Click on autoruns.exe to start the utility.

Once the utility launches, select the Explorer tab and look for OptaineIconOverlay in the first column and OptaneShellExt in the second.  Just uncheck the checkbox at the beginning of that row and you are done.

Note that we detected the Intel shell extension issue on systems with the latest iteration of Intel's  Rapid Storage Technology software is so updating that software is not possible let alone likely to produce favorable results.

[td]

Quite by accident, I discovered that the Intel Rapid Storage Technology shell extension can be uninstalled without having to uninstall the other Rapid Storage and Ready Mode components.  On Windows 10 go to Settings->Apps->Apps & features.  Look for an application with "Optane" in its name.  Might be a tiny bit simpler than using autoruns.exe.

[Mik Luciuk]

TD

For the life of me, I cannot "detect" any Intel Rapid Storage Technology installed on my Lenovo T470. I see zero references to "Optane".....

Can't find or see it, thus not able to disable it.

Any other idea(s)?

[td]

Have you tried the System Internals application?

[td]

I should have added that the point of using the System Internals autoruns.exe utility is to identify the shell extension that is causing the problem.  You could do this by disabling each shell extension in turn until the 64-bit compiler's file dialog works correctly.  Or you could disable them all and add them back in until the file dialog stops working.  Of course, if the file dialog doesn't work with all extensions disabled, you have a different problem. 

Taking this course of action would allow you to use the 64-bit compiler's file open dialog UI and provide us with needed information to pursue this issue farther.

[jat6923]

I having this issue as well.  The work around didn't really work.   

Used the Autorun utility and found that the shell extension TITUSICONOVERLAY needed to be disabled to make work.   

A case has been opened with Titus International for this issue, but they are currently stating the problem appears to be an unhandled scenario by Winbatch.

[td]

People say a lot of things but without evidence, it is mostly just noise.  If we come across actionable information that indicates that the compiler has a problem, we will fix it.  Otherwise, we have already conducted an extensive investigation and found no evidence that the compiler is the root cause.  Not saying that it is not the cause.  Just saying that there is no evidence at this time.

There a multiple workarounds for the problem if you don't want to disable a shell extension.  The 32-bit compiler solution will work if performed correctly and you can always edit or create a cmp file so you don't have to use the file open dialog.

[td]

We believe we have found a solution to this annoying inconvenience.  It appears that some .Net based shell extensions are very greedy resource piggies so we think we can fix the problem by fattening up the 64-bit compiler some.  Assuming that further testing confirms the results we have seen so far, the fix will be in the next release.