My old 2.2 GHz PC, who connect fine, is on Win 7 64 bits Ultimate.
I just ordered i7 3.4Ghz 8GB of RAM and hopefully it will show the problem for us.
@ Gus
If it doesn’t show the problem, please feel free to donate it to me 
Pete
Yes sure 
It has 2TB hard drive!! Why would anyone need that much hard drive. Crazy!
I was proud of my first x86 because all my friends had 40mb but I had a whopping 120mb hard drive. Wow!!
For information, I’m using the USB Client red module. Not the Dual Power module.
Robin Brockett said to me two weeks ago that this module was “new”…
Do someone else having this problem uses the non DP module?
I have verified that I have the problem with both the DP and SP modules.
My current theory is that the problem is related to processor speed.
It might be caused by radio communications from an alien space ship orbiting the earth, but I need some more data before mentioning this theory.
Mike, it sounds like Gus needs to have his new computer sent to you and you send yours to him
I have the USB Client SP Module. Not the DP. Wondering if a lack of external power might be the cause.
I wish I could send my computers to Gus, but both contain stuff from work.
If Gus does not see the problem on his new machine, he may have to send it to me to do a complete install. I may have extra special skills at screwing things up…
I’ve tried with both the DP and SP modules. I’ll try running everything on a VM … I wonder if that will make a difference.
The big standout for me is that loading the tinybooter works 100%. I’ve done that several times now and it is always perfect.
It’s using the tinybooter to load the MF code that seems to have the problems (and deploying the code itself). Is it possible that the issue is in the tinybooter?
Phil
Anything is possible.
The GHI staff has been working hard on this issue.
Once Gus gets his i7, and sees the problem (fingers crossed), we will have a quick solution.
I didn’t mean that critically - I thought it might be a helpful observation.
I’m also happy to do a USB trace if that’s of interest.
Phil
I was being critical about your comments. 
I was just trying to assume you that GHI is on the problem…
I think Gus might like a USB trace.
A little bit of additional information … I installed everything in XP mode on my Win7 x64 box (basically a Windows Virtual machine) and I managed to get MFDeploy to deploy the foirmware, though I still cannot get a program deployed to the device. I’ll keep working on some other things, but it would be interesting if someone else having the issue would try XP mode, especially those with a boundary issue (ie working sometimes … mine is a hard fail).
One last test complete. I installed VS2010 and the .NET environment into a Windows XP machine on a VMWare Workstation VM. It works fine there. The VMWare VM is much slower thana windows Virtual PC one. So, to summarise…
All on the same USB port.
[ulist]Win 7 x64, fast quad core laptop … Only installing the tinybooter works.
WinXP 32 bit on fast Microsoft Virtual PC VM on above laptop - can load firmware but not deploy from Visual Studio and cannot ping from MFDeploy.
WinXP 32 bit on slow VMWare VM on above laptop - all works,[/ulist]
So, weird as it seems, PC speed is definitely the issue. And it seems to be related to the tinybooter.
Phil
Phil:
What you are seeing closing matches what I have been seeing. 
I can load the firmware, but not deploy. What is happening is during the deploy process, the Hydra is getting reset, and seems to be unable to reset. The Device manager says it was unable to start the driver and the error code is 0xa/10.
I have been able to deploy under VS, under win 7, by starting the deploy process, and then going to the Device Manager and then use the troubleshooting tool to reload the http://tinyclr.com/forum/reply/21/5470#driver. If done fast enough, VS then sees the Hydra reseting and successfully deploys.
Hi Guys,
i didn’t try this but maybe you guys can disable the windows automatic driver installation, so this way windows will stop trying to install the driver every time the Hydra resets… try the following steps…
Go to Start–>Search type in gpedit.msc
Click the file to open the Local Group Policy Editor and show Windows who is in control!!
You want to go here: Computer Configuration->Administrative Templates->System->Device Installation.
Click on the subfolder Device Installation on the left and on the right side you will see the possible restrictions.
Right Click on Prevent Installation of Devices not described by other policy settings and edit this option, set it on ENABLED.
Reboot Windows
to turn it back on:
open gpedit.msc again and revert the change so you will be able to install your driver.
i hope the above steps helps.
Jay.
I tried Jay’s suggestion and it didn’t help unfortunately.
I also tried to running VS with the log switch (devenv /log) and didn’t see anything meaningful in the log file.
Is there any ways we can log to give Gus a better idea on what’s going on?
Gus has ordered an i7 3.4GHZ PC. As soon as he gets the machine, and recreates the issue, we should see a fast resolution.
We just received the machine: Intel i7-2600 @ 3.40GHz with 16GB RAM and 64-bit Windows Home Premium. Updating firmware, ping from MFDeploy, and deploying a project from Visual Studio worked on the first try. 
If someone with a computer that has this problem can let us borrow it, we can send them a gift for the help.