Topic: Strange Network Behavior with 32-bit apps in 64-bit build...  (Read 686 times)

0 Members and 1 Guest are viewing this topic.

Strange Network Behavior with 32-bit apps in 64-bit build...
« on: January 19, 2017, 10:27:49 AM »

evanevery

  • Apprentice
  • *
  • Date Registered: Jan 2017
  • Posts: 5
The SSD I had my Win8.1se build environment on crashed a couple of weeks ago.  I had a backup that was several months old, so I restored the files.  I had only made a couple of changes in the last couple of months so I figured it would be no big deal to get the backed up build environment caught back up.  I encountered a major problem (which I ultimately solved) but I have no idea why my resurrected environment is behaving differently.  There is a bunch of info here, but I will be as concise as possible:

1.  I am using a mounted ISO of the Win 8.1 64-Bit Microsoft installation CD ("with Update").  (My environment is 64-bit)  I have actually tried multiple Win8.1 64-bit ISO's from MS (inc without "Update")...

2.  I have a custom network logon (drive mapping) tool which I wrote and compiled with AutoIT (latest Version).  Typically I compile for 32-bit regardless of the operating environment.

3.  In the "new" (resurrected) build environment, my logon tool refuses to map any drives with a network 1222 error ("Network Not Started or Unavailable")

4.  I still have the end product of the "old" (Original) build environment.  (I use the boot.wim in a PXE boot environment).

5.  Even if I extract my logon tool from the original "boot.wim" file, I still get the same error (1222).  This does not happen if I boot to the original boot.wim file (via PXE)

6.  I have been back and forth (it seems like a hundred times) to confirm my "new" build environment matches my "old" build environment.  To the best of my knowledge all the build options are identical.  I even have notes!

7.  The RESOLUTION to the problem was to compile the AutoIT network application as a 64-bit executable.  But I'm not sure why I had to do this.  The original was a 32-bit executable and worked fine in the 64-bit build.

8.  I have checked to ensure that 32 bit "WOW64 Basic" services were enabled.  I even tested the issue by making a bare minimal AutoIT executable which simply mapped a single drive and it still failed if it was compiled for 32 bit executable ("DriveMapAdd" function).

9.  I see no option in the NETWORK or the PENetwork components which would seem to impact 32/64 bit compatibility.

10.  All native windows services (command prompt, explorer, etc) seem to work (map drives) in either environment properly.

I have no idea why 32 bit AutoIt executables are having problems working with the network in my "new" 64-bit environment.  Obviously, something has changed between my old and new build environments, but I have no idea what that might be.  Anyone have any insight or suggestions?

Re: Strange Network Behavior with 32-bit apps in 64-bit build...
« Reply #1 on: January 19, 2017, 11:14:13 AM »

Lancelot

  • Gena Baker
  • Grand Chef
  • *****
  • Date Registered: Sep 2010
  • Posts: 7236
Obviously, something has changed between my old and new build environments, but I have no idea what that might be.  Anyone have any insight or suggestions?

After reading all carefully  :thumbsup:

Shortly:

Most Frequent:
one of application plugin you used before not used later,
 or one of application plugin updated and now supports x64 natively..........

on both cases, some dependencies changed provided by A application plugin,
 which effects B application (x86 on most frequent, still x64 too ) not work anymore
 .......



***
To avoid such things,
Develop your application and related plugin to work with a Basic build:
http://theoven.org/index.php?topic=1876.0

on your case,
after basic build ("Basic Project"),
+ run PeNetwork plugin (green play button)
+ run Network plugin (green play button)
+ run your personal application plugin (green play button)
=>
finally run "Basic Project" plugin again (green play button)
===>
and test, faster on a virtual environment
\VirtualTest\
plugins available....
or
real environment....
(at least after you feel virtual tests ok, than continue real environment tests to gain time)


Than plugin and application will mostly work without problem today and tomorrow,
 and if there happens a failure it will be quite easier to figure out and fix on such plugin. (very RARE)


ps:
project plugins and most used plugins designed that way,
 so we do not have such failures on project development and plugins,
   as a result we can focus on other things on our very very limited free time.  :wink:

Overall good luck  :thumbsup:

:turtle:
« Last Edit: January 19, 2017, 11:17:47 AM by Lancelot »

 

Powered by EzPortal