COM/CLR Exception - but only as an .EXE

ch_Jake · March 04, 2015, 08:51:41 AM

Hi, long-time lurker, first-time poster ... thanks in advance for any assistance!

We mainly use WinBatch to create the perception of single sign-on by automating the login process for some of our peripheral applications; most are web-based, and the process is simple: open a browser, navigate to a URL, enter the credentials, click a button, and get out of the way.

I'm updating a script that started giving our Win7 machines fits ... only to find that while the script runs perfectly in Studio, it chokes out at a certain spot as an .EXE. The error code is "1261: COM/CLR: Exception." Not terribly forthcoming (at least for me).

The scenario: as described above, I have a script that open a browser, and navigates to a landing page which consists of a nested frameset (FS1 has 2 rows; second row of FS1 contains 2 columns, so the frame borders make a 'T'):

Code (html5) Select

<frameset framespacing="0" border="false" rows="110,*" frameborder="1">
	<frame name="NavHeader" scrolling="no" noresize src="NavHeader.Asp">
	<frameset framespacing="0" border="false" cols="200,*" frameborder="1">
		<frame name="NavBar" scrolling="no" noresize src="NavBar.Asp">
		<frame name="NavMain" scrolling="auto" noresize src="NavMain.Asp">
	</frameset>
	<noframes>
		<body bgcolor="#E7DECE" text="#000000">
		<p>Your Browser Must Support Frames.</p>
		</body>
	</noframes>
</frameset>

Once this page loads, I need to make one frame ('NavMain') navigate to a new URL which contains the login form. It's here where my .EXE dies (in bold):

Code (winbatch) Select


	objIE = ObjectCreate('InternetExplorer.Application')
	objIE.addressbar = @TRUE
	objIE.statusbar = @TRUE
	objIE.menubar = @TRUE
	objIE.toolbar = @TRUE
	objIE.visible = @TRUE
	objIE.navigate(inLaunchURL)
	objIE.Visible = 1
	While objIE.busy || objIE.readystate == 1
		TimeDelay(1.0)
	EndWhile

	objIE.document.frames(2).navigate(inLoginURL)

I'm using 2015A, on a Windows7 64-bit machine, and I get the same 1261 error whether I've compiled a 32-bit or 64-bit EXE (I need a 32-bit, ultimately). Alternatively, I've tried making a collection of the navigation links (which live in the 'NavBar' frame) and clicking the necessary one to bring up the login form - but this was giving trouble as well, plus I figured it was a little neater to just .navigate() to the page I wanted then to create & walk an array then click a button. Besides which, the HTML in this application is rather poorly written (all navigation buttons are in a form, all with the same NAME and ID, only the VALUE differs. HTML fail.)

Anyway - I'm stumped, especially since the script works just fine running from the studio, or even as a link from the Debug menu. Help? If I'm missing something or can provide more info, just let me know. Thanks in advance!

td · March 04, 2015, 10:08:30 AM

Unfortunately, WinBatch is dependent on COM Automation servers for text based error information when a COM exception occurs and COM server implementers, including MSFT, are not consistent in providing that info. If there is any additional information to be had it can be displayed by pressing the "More Error Info" button on the WinBatch error dialog. In a coming version of WinBatch we will be including any available system error codes to the additional error information when text is not available. While error codes are not a perfect solution, something is better than nothing.

Your specific problem could be the result of the manifest settings of your compiled script if UAC is enabled on your system. The default for WBT files executed with the 'Run' command in WinBatch Studio is execution level of 'highestAvailable' and uiAccess set to 'true'. If you are not already using those settings, you should test compiling your script with the same settings. Setting uiAcccess to 'true' may require placing you exe in a secure location like Program Files (x86) to get it to execute. This will depend on UAC related GP settings.

Other than UAC related manifest settings, there isn't anything magical about compiled scripts. The only other possible difference of note between a compiled script and a script executed from the WBS Run command is the location of the script running executable on the file system.

ch_Jake · March 04, 2015, 10:46:39 AM

Well, that explains it. 'highestAvailable' at least lets the .EXE function as advertised ... with the exception of the UAC allow/deny prompt before it does anything. Moving it into a Program Files directory has no bearing on whether or not that UAC window comes up though. If I/we were to sign our .EXE, would that allow us to forgo the UAC speedbump and just let the .EXE do its thing, unhindered? Or is there something we can do from a Group Policy perspective (this is only going to run on our networked PCs)?

Thanks for the detailed explanation!

ch_Jake · March 04, 2015, 12:01:27 PM

It seems I have another wrinkle to contend with, one that may or may not be satisfied by signing my .EXE. We have several such .EXEs like this one, which are called from a web application we use, a 'dashboard' of sorts. This dashboard has several ActiveX objects which allow it to push .EXEs to the client machine (and update them when necessary), and then execute them (when a user clicks on a button, on the site). This isn't a public-facing app, as it does a number of generally-frowned-upon-on-the-web things. When I call my new highestAvailable .EXE through the context of this site, it really blows up. A not-very-helpful-or-informative error from the website; presumably, it doesn't like the highestAvailable UAC setting - and I'm guessing because the .EXE is not executing under the user's permissions, but some lower-level machine account (executing via the ActiveX object). Nothing I think I can do anything about, so I'm not worried about that. However, I don't believe I'll be able to 'push' these .EXEs into the Program Files\ directory; so my question to you is whether or not signing them would allow us to forgo storing the .EXE in the Program Files directory as well as, would the signed .EXE get us past the 'highestAvailable' UAC setting as well?

Barring that (and I think I know the answer, but thought I'd ask, anyway), is there a GP setting that would let this .EXE operate normally, and do you know what that would be?

Thanks again!

td · March 04, 2015, 01:07:54 PM

Quote from: ch_Jake on March 04, 2015, 10:46:39 AM
Well, that explains it. 'highestAvailable' at least lets the .EXE function as advertised ... with the exception of the UAC allow/deny prompt before it does anything. Moving it into a Program Files directory has no bearing on whether or not that UAC window comes up though.

Moving an application to a protected folder does not affect the UAC prompt. Usually the default UAC GP settings do not allow uiAccess = TRUE manifested executables to run from unprotected directories and also require that the exe be signed. If these conditions are not met you can get an "A referral was returned from the server." error. This behavior can be modified to some extent by changing group policy. However, if your exe is working by setting executionLevel to 'highestAvailable' without setting uiAccess to' true' then you don't need to worry about the protected directory business.

Quote
If I/we were to sign our .EXE, would that allow us to forgo the UAC speedbump and just let the .EXE do its thing, unhindered? Or is there something we can do from a Group Policy perspective (this is only going to run on our networked PCs)?

Thanks for the detailed explanation!

The one sure way to avoid the UAC prompt is to disable UAC but that is not recommended by most 'security experts' and not allowed by many institutions. There are a few other quick tricks with the Task Scheduler but that doesn't work with Windows 8 and newer. You can get more information about UAC and WinBatch by searching on UAC in the Tech Database.

UAC has been around since 2007 and most Winbatch users have learned to accept it as a part of using the Windows OS.

td · March 04, 2015, 01:38:11 PM

Quote from: ch_Jake on March 04, 2015, 12:01:27 PM
It seems I have another wrinkle to contend with, one that may or may not be satisfied by signing my .EXE. We have several such .EXEs like this one, which are called from a web application we use, a 'dashboard' of sorts. This dashboard has several ActiveX objects which allow it to push .EXEs to the client machine (and update them when necessary), and then execute them (when a user clicks on a button, on the site). This isn't a public-facing app, as it does a number of generally-frowned-upon-on-the-web things. When I call my new highestAvailable .EXE through the context of this site, it really blows up. A not-very-helpful-or-informative error from the website; presumably, it doesn't like the highestAvailable UAC setting - and I'm guessing because the .EXE is not executing under the user's permissions, but some lower-level machine account (executing via the ActiveX object). Nothing I think I can do anything about, so I'm not worried about that. However, I don't believe I'll be able to 'push' these .EXEs into the Program Files\ directory; so my question to you is whether or not signing them would allow us to forgo storing the .EXE in the Program Files directory as well as, would the signed .EXE get us past the 'highestAvailable' UAC setting as well?

Barring that (and I think I know the answer, but thought I'd ask, anyway), is there a GP setting that would let this .EXE operate normally, and do you know what that would be?

Thanks again!

It is likely that your Active X objects are running with restricted Admin privileges and attempting to create a processes using the one of the CreateProcess related Win32 APIs. This will result in an access deny error of some kind because this is simply not permitted by the OS when UAC is enabled. The only way to start an elevated process from a restricted process is to use ShellExecute* Windows shell APIs which your Active X controls are apparently not doing. Signing an exe will not change this behavior nor will it prevent the need to run an executable with full admin privileges, i.e., 'highestAvailable'. As previously mentioned, you don't need to worry about placing the exe in the 'Program Files (x86)' folder unless you need to set uiAccess to 'true'. Also remember 'highestAvailable' has no effect on standard users because standard users don't have any additional privileges.

There are several UAC related GP settings that modify the behavior of UAC. However, the only setting that will affect being able to start elevated exes from restricted processes without a UAC prompt or using a ShellExecute* function is to turn UAC off.

It is highly recommended that you familiarize yourself with the ins and outs of UAC. It has been around for 8 years and isn't going away any time soon.

ch_Jake · March 05, 2015, 10:33:52 AM

Wow. Thanks, td. It's a rare thing, getting such a solid, thoroughly detailed, qualified response. (If only everywhere else were as thorough!)

Quote from: td on March 04, 2015, 01:38:11 PM
It is highly recommended that you familiarize yourself with the ins and outs of UAC. It has been around for 8 years and isn't going away any time soon.

I'll spare you the tale of woe regarding our horrifically slow adoption of anything new. I just got a Win7 box last month, and only because my old XP machine died a fiery death. We're still fighting to get away from IE8, and I'll just leave it at that. ;)

But seriously, thanks again for your thorough support. It is truly rare, and highly appreciated.

News:

COM/CLR Exception - but only as an .EXE

ch_Jake

td

ch_Jake

ch_Jake

td

td

ch_Jake