-1

I have an Executable I am able to run in the Dev environment that isn't being run in the Int environment. When I try to run the .EXE on Int remotely using UNC path I get an error stating the .EXE is a 16-bit application and can't be run on the Int machine. The problem with that error is I built the .EXE and know for a fact it isn't a 16-bit application. When I try to run the SSIS package to call the .EXE on Int I do not receive the 16-bit error, but the .EXE is not run.

I have tried hard coding the location of the .EXE in the execute process task and using a variable that dynamically sets the location based on the machine I am running the SSIS package on. (Both work in Dev, neither work in Int) I can also call the .EXE on Int from Dev, which isn't a surprise since the .EXE is pulled down from Int to Dev.

Any ideas why the .EXE would run on a Dev environment but not an Int environment? The environments are the same per our System Admin.

mungea05
  • 110
  • 6
  • What's the exact error? post it. Have you tried simply running it directly from the command line over the UNC? – Nick.Mc May 17 '14 at 13:54
  • The exact error is: Unsupported 16-Bit Application. The program or feature "EXE" cannot start or run due to incompatibility with 64-bit versions of Windows. Please contact the software vendor to ask if a 64-bit Windows compatible version is available. When the DBA runs it on the server he gets the following error: NTVDM encountered a hard error. [Execute Process Task] Error: In Executing "EXE" at "filepath", The process exit code was "128" while the expected was "0". – mungea05 May 21 '14 at 20:16
  • That's pretty mystifying. That's two messages saying its 16 bit. When you run it on DEV does it start NTVDM.exe process? – Nick.Mc May 21 '14 at 22:52
  • DBA says we aren't able to see if NTVDM starts unless it fails on Dev. the application isn't 16-Bit. It's developed using VS2010, with .NET 4.0 on a 64-bit machine. It's a simple console application that calls an API and creates a behavior extension to get a limited time service key, then kick off a task via the API. – mungea05 May 22 '14 at 14:49
  • I don't quite understand you response - do you ever see NTVDM.exe? It's difficult to troubleshoot like this and I am not an expert but something thinks it's 16 bit. I assume you are using an appropriate target architecture when compiling, and there is nothing wierd in the API you are using? – Nick.Mc May 23 '14 at 01:25
  • I just inspected the EXE on all 3 environments its currently on. On my local machine, its 32-bit, on Dev its 32-bit, and on INT its DOS. I don't move the file from Dev to INT, so this might be a file transfer issue??? – mungea05 May 23 '14 at 14:15

1 Answers1

0

I have an answer to the issue for those concerned.

The problem was with the file transfer process that was moving the EXE from the Dev server to the Int server. The process was handled via a Robocopy script (which I still am unable to get the parameters of), which appeared to be causing the issue.

I am not 100% sure what caused the issue, but the script wasn't copying over the assembly and without the assembly the server thought the EXE was a 16-bit application.

Helpful links to diagnose the problem:

Run this powershell command script to determine the "bitness" of the app on each server.

mungea05
  • 110
  • 6
  • Glad you got it sorted! Is the assembly a separate file? That looks like a very handy script, I've never been able to work this out. – Nick.Mc May 23 '14 at 22:37
  • The Assembly information is a file in the properties portion of the executable. Robocopy must be ignoring properties files during the transfer. – mungea05 May 27 '14 at 13:32