I have both installed on the same box. There are DTBGGP64.pth and a Server10.1.pth files in the C:\Python27\ArcGISx6410.1\Lib\site-packages folder. The first points to the the C:\Program Files (x86)\ArcGIS\Desktop10.1\bin64 folder and the second points to the C:\Program Files\ArcGIS\Server\bin folder. This seems to be a conflict.
When I enable background processing and debug into a Python geoprocessing task it fails when arcpy is imported. Printing sys.path reveals:
Note that it is pointing to the 32-bit Desktop bin folder, before the 64-bit Desktop bin64 folder is pointed to. Where is all these extra path entries coming from?
I need to publish the geoprocessing task to Server. In the past we have used ArcMap on the Server box in authoring our web applications, which call a geoprocessing task. Is this not possible anymore?
It has miraculously started working. I did nothing other than update the legacy "import arcgisscripting... arcgisscripting.create()" to "import arcpy" and rearranging some of the embedded debugging messages.
I may have this figured out. For me the breakage seems to only happen when using the 64-bit version of PythonWin and only when ArcMap opens PythonWin. I.e., Pythonwin is closed when the debug session is started from ArcMap.
Based on the information your presented here and the bug that was logged, we now know its because of the path and its contents when you launch an IDE from ArcMap (right click on script > edit for example). If you launch the IDE by itself, the path is fine. When launched from ArcMap you'll see the 32bit path in the sys.path: c:\\program files (x86)\\arcgis\\desktop10.1\\bin
As a hack, you could do this:
import sys
sys.path.remove('c:\\program files (x86)\\arcgis\\desktop10.1\\bin')
import arcpy
#rest of your script
Or if you're using an IDE that you set the Python interrupter, like WING for example, you can qualify which Python it should run against (like the 32bit one) Or using a 32bit IDE will work fine as well.