Thread.Sleep(Timeout.Infinite) = debugger engine failed to initialize

[kodfilemon]

STM32F4Discovery, VS2013
Debugger engine init fails (every next start debug) when Thread.Sleep(Timeout.Infinite) in Main procedure. VS output window:

Looking for a device on transport 'USB'
Found device port 'USB' with ID '8a381d09-b2d4-4ff8-a3fe-0e6a36db391b' for transport 'Usb'
Starting device deployment...
Attempting to connect to device 'USB:a7e70ea2' Iteration 0
Opening port ?\usb#vid_0483&pid_a08f#5&87a71d2&0&4#{d32d1d64-963d-463e-874a-8ec8c8082cbf}
Attaching debugger engine...
... debugger engine attached!
Querying device assemblies...
Found Assembly mscorlib 4.4.0.0
Found Assembly Microsoft.SPOT.Native 4.4.0.0
Found Assembly Microsoft.SPOT.Hardware 4.4.0.0
Found Assembly Microsoft.SPOT.Hardware.Usb 4.4.0.0
Found Assembly Microsoft.SPOT.Hardware.SerialPort 4.4.0.0
Found Assembly Windows.Devices 4.4.0.0
Found Assembly MFConsoleApplication1 1.0.0.0
Attempting deployment...
Incrementally deploying assemblies to device
Deploying assemblies for a total size of 2948 bytes
Assemblies successfully deployed to device.
Restarting interpreter...
Attaching to device...
Waiting for device to initialize...
The debugging target and the debugger engine failed to initialize because of unspecified device errors.
The debugger engine thread has terminated unexpectedly with error 'Could not reconnect to the debugging target after rebooting it.'.

[cw2]

Could you please be more specific about what toolchain did you use to compile the firmware (GCC or MDK, version)? Did you made any modifications? What is the minimal code that still reproduces the problem? Just Thread.Sleep(Timeout.Infinite) in otherwise empty Main() ?

[kodfilemon]

I use this toolchain :) https://github.com/cw2/cw2.github.io/tree/master/downloads. Without modyfications. But i check also Lorenzo prebuild image http://t.co/TfTCE0EEbY. Minimal code to reproduce:

public static void Main()
{
Debug.Print("Hello");
Thread.Sleep(Timeout.Infinite);
}

Run this code twice. On second run i got this error.

[cw2]

Hm... Are there any static members in your program? Like ports (or other peripherals) being initialized before Main()?

[kodfilemon]

No. Just this simple program to reproduce problem. Maybe problem is in USB driver?
I have in device manager: WinUSB generic Device. It is Ok?

[cw2]

The USB device should be "STM32F4DISCOVERY" (friendly name "a7e70ea2").

[kodfilemon]

I removed WinUSB device. Now i see STM32F4DISCOVERY device but with yellow exclamation (no driver). It is good instruction to make driver for version 4.4? http://download-codeplex.sec.s-msft.com/Download?ProjectName=netmf&DownloadId=462464

[smaillet-ms]

@kodfilemon No - those instructions are not applicable to v4.4 there is no longer any need to build drivers or create singed INFs etc... In general all content on the CodePlex site should be considered obsolete for legacy support reference only.

For more info on USB see this discussion #215 at some point I'll write up a wiki to explain it all, but the bottom line is if you follow the reference MCBSTM32F400 implementation you don't need a custom driver (But you DO need your own VID if you plan on shipping or avoiding conflicts with other devices)

[kodfilemon]

Results of my investigation: driver for MS_COMP_WINUSB is automagically installed only on Windows 8 or higher. Full plug and play. On Windows 7 (my case) automatic driver update will help but sometimes no. In this case you need to download and manually install Microsoft - Other hardware - WinUsb Device from catalog.update.microsoft.com. So, on Windows 7, Discovery board is recognized like "WinUSB Device". It is ok. Incidentally, on Windows 8, provider name is: Windows Phone.
Usefull links: how to install winusb sys without a custom inf and Microchip Forums.

Drill down. If my USB is ok problem is elsewhere. I made little changes in procedure CorDebugProcess.AttachToEngine. In line 438 I replaced Thread.Yield() to Thread.Sleep(10) and my problem disappeared.

[smaillet-ms]

Thanks for the research, I was under the impression that Windows update was supposed to auto update WinUSB all the way back to Windows 7. Interesting to know it doesn't always happen so manual intervention might be required.