Another black screen on MNGP after update

[Susido]

My scenario appears identical to what happened to offgridQLD in his thread below. I decided to start a new thread as that one has kind of gone off-track.

Windows 10 update to rev 2079 appeared to go perfectly. Updated my Classic 150 just fine (not sure as to previous version but it was from last year). Then updated the MNGP and that appeared to work fine too. Attempted to do the Factory Restore by holding down left and right arrow buttons but the MNGP display remains black and the Red (Comm?) light is on constantly (perhaps evidence the MNGP is truly non-functional).

Retried MNGP update several times, updater always claimed success but no display. I did succeed with the hardware version of using jumpers to factory reset but no display (super fun with a pair of tweezers and freezing hands...). Then I tried the middle position for the MNGP cable connector but that results in the updater unable to update the MNGP at all (doesn't seem to find it). 

Unlike offgridQLD, I don't have the local app functioning - it was what I planned to do right after this update. So I don't know if the 2079 update actually worked on the classic but I suspect it did and only the MNGP isn't functional. I don't have any more laptops with Windows 7 installed unfortunately but I do have an old desktop with Win7 I may drag out to the shed tomorrow and try the update again as that is what appeared to work for offgridQLD.

[boB]

Sorry about your trouble, Susido.

Yes, give windows 7 a try.  However, windows 10 should have worked just fine.

Please report back with your success or not.  Otherwise we can do some kind of swap or whatever needed to get you going again.

boB

[boB]

Susido, I just now heard from Matt (he evidently read this thread) and says to try this....
Matt is the one who wrote the new update software so knows  way more about it than  I do at this point !

"
They should install the 2015 C++ redistribution package:

https://www.microsoft.com/en-us/download/details.aspx?id=48145
"

Please give this a try on your windows 10 installation  and see if it helps your problem.

boB

[Resthome]

Susido, I just now heard from Matt (he evidently read this thread) and says to try this....
Matt is the one who wrote the new update software so knows  way more about it than  I do at this point !

"
They should install the 2015 C++ redistribution package:

https://www.microsoft.com/en-us/download/details.aspx?id=48145
"

Please give this a try on your windows 10 installation  and see if it helps your problem.

boB

I'll wait for the OP to give this a try. But I'm skeptical on this. Seem to me you wouldn't be seeing the Classic portion complete and you shouldn't be seeing Successful Completion messages if there was no C++ redistribution package on the machine. If C++ was used to create the Win10 firmware uploaded it needs to be in the install package. But what do I know maybe it wil be the magic potion to get the starship pointed in the right direction. 

[Susido]

Well this morning I hauled out my beastly old Windows 7 desktop and peripherals and successfully updated the MNGP without issue. What a relief.

Unfortunately I did this before reading about installing the C++ package and since my system is back up and running, I really don't feel like additional experimentation. But IMHO the Windows 10 installer (as is) cannot be trusted to update the MNGP!

[Susido]

I should add that I really do appreciate the help offered by Midnite support, it's a big reason why I choose the Classic and other Midnite products.

If it helps at all, my Windows 10 laptop did not have the Visual C++ 2015 package installed but did have 2008/2010/2013 C++ packages.

[Resthome]

Went and looked at the dlls provided with the WIN10 installer from Midnite and the msvcp140.dll is included in the zip file. This is the file for Standard C++ Library for native code for C++ version 2015 (V14).

I only have the 2005/2008/2010/2012/2013 Redistribution packages installed on my Win10 laptop. And the 2010/2012/2013 were updated on 2/16/2016.

So are we still saying that the whole 2015 C++ redistribution package is required?

[Westbranch]

I went to the MS site and it appears that the 2015 version also works on W7 and up...

So is it prudent to add the update to a W7 machine ?...

That address told me there is a lot of stuff I don't need (want?) in the Upgrade... it seems to be a CYA package...

[Matt]

Let me just start by saying I'm sorry to anyone who is having trouble with the updater. I really don't like seeing these responses on the forum (truly).

Ok. The main updater code was compiled with: .NET 4. .NET 4 was used because it works on all operating systems from XP to Windows 10 (this has been tested). The serial communication library was compiled using: C++ 2015 redistribution. With these two dependencies covered, you can get the updater to work on any Windows from XP to Windows 10 (As of 11/01/2015).

The two C++ redistribution .dll's (msvcp140.dll and vcruntime.dll) in the Classic Programmer directory are the dependencies required to use the serial library for the updater. Windows 10 already comes with fairly updated C++ runtime files. In fact, I have never seen Windows 10 fail updating a MNGP with a stock setup (No updates). Some lower versions of Windows will require the full install of the 2015 C++ redistribution package (EX: XP). I recommend installing the full 2015 C++ redistribution regardless. You would be surprised to know (in a lot of cases), as long the naming convention is met, Windows will try to use any old file. In fact, if you want to use the old usbser.sys instead of the new Windows 10 one, you can just copy it into Windows/system32/drivers/ and it will use it just fine (I don't recommend trying this). 

I have seen blank MNGP's on a couple test setups that were not using Windows 10. Installing the 2015 c++ redistribution fixed the issue. This may or may not work for you. If you try it, I would delete the msvcp140.dll, and vcruntime.dll from the Classic Programmer directory. The default setup is to use .dll's in local folders first. If you delete them (or move them out of the directory) you are guaranteed to be using any updated .dll's.

If you get to 100% percent it literally means it transferred all the data. There is only one instance where this would not be true, and in that instance you would not have a blank MNGP. The Classic MUST send back an "OK" response for further data to be transmitted from the computer. There are no exceptions. If it freezes at some point on the progress bar (above 0%), this is more than likely a physical transmission issue (cable). If the MNGP takes longer than 8 - 10 minutes to update and doesn't actually update, (no harm, no foul) you have missed the update Window (try again). On the main screen if you hit Control + ALT + C it will bring up the undocumented diagnostic console. Here you can verify the file selected and update status. If you didn't have C++ redistribution installed, here is where you would get a ridiculous amount of error messages.

I would love to be able to replicate this issue, but I can't. I have never had a problem updating a MNGP from Windows 10 using the new updater. I have now heard of 3 instances of this particular problem. It would basically require the computer and Classic to replicate the environment that causes this issue. If anyone one wants to be forward with the make, model and year (serial number) of their Classic and the make, model, and specific Windows 10 build (32 bit, 64 bit, Home, Pro, OEM, etc...). It may help shed some light on this problem. And no, the full 2015 C++ redistribution should not be required in Windows 10, but I have no idea what updates and changes have been made to every computer the Classic updater touches. There is a installer/updater in the works that should be compatible with all versions of Windows. Unfortunately, I am completely out of that particular loop.

-Matt

[Susido]

Good that you're looking into this Matt. Mine is a Classic 150 installed in 2013, serial #6749. Laptop used was a Lenovo Yoga2 Pro with Windows 10 Home 64 bit upgraded from Windows 7 Pro. Not that it's feasible to avoid doing so but the laptop has been updated with all Microsoft required Windows 10 updates for at least 6 months now.

Hope you can get to the bottom of this. Though from now on I think I'll be sticking with updates made from a Windows 7 machine.

[Resthome]

Yeah doesn't make a lot sense. If all the MNGP code gets transferred why is the MNGP refusing to come alive after a VMM. The Rem file is the same as the one used for the Win7 update. I guess the question is just because the Classic MNGP acknowledged the transfers does it known if the correct bits where received.

Is there something that is suppose to transpire after the code is dumped to the MNGP that for some reason does happen with the Win10 code. I know with the Win7 and Win8.1 process you get the successful complete in the dos box but you need to wait ~2 minutes before the dos box closes and then reboot the Classic.  Not sure what is going on during that time if anything. Maybe boB knows!

BTW I believe the usbser.sys files are left in the driver folder when the Win10 is updated from a previous version. But I wouldn't think the new Win10 code would be trying to use it since the new driver is in the local folder.  Another mystery left for those with more knowledge than me.

[dgd]

Thanks for your detailed reply Matt.

I always wondered why, in previous to W10, the FW uploader program would display on screen 100% complete BUT the upload would generally fail if the Classic was rebooted. The well known solution was to wait until the uploading window closed (by disappearing), this usually taking from a few tens of seconds to a couple of minutes.

It was only when I wrote W10 C++ code that input and output data from serial port and found that writing data did not always seem to be completed that I realised the serial port ring buffer was not being flushed when the final bytes of data were sent to the port.
There appeared to be a significant delay before some timeout for the ring buffer to actually transmit the bytes waiting in the queue.
If the receiving end was waiting on the complete file then it never received it if it was a processor that was rebooted (as the Classic is). The file being rejected, failing CRC or whatever.
So is there a remote chance this is what is happening here with the W10 uploader.
Working on some W10 computer and not others because they have different implementation of USB drivers

Isn't there is a serial port flush buffer command available?
http://www.cplusplus.com/reference/cstdio/fflush/
Maybe an fflush() just to be sure, before the fclose()   

Just an idea, but probably not applicable here 

dgd

[Resthome]

Good thought dgd.

You may have hit on something. Not sure where Mat snagged the Serial_W32_Lib.dll from it is date Dec 15, 2015 and was modified on 18th. It is located in the local folder with the exe. 

[boB]

Yeah doesn't make a lot sense. If all the MNGP code gets transferred why is the MNGP refusing to come alive after a VMM. The Rem file is the same as the one used for the Win7 update. I guess the question is just because the Classic MNGP acknowledged the transfers does it known if the correct bits where received.

Is there something that is suppose to transpire after the code is dumped to the MNGP that for some reason does happen with the Win10 code. I know with the Win7 and Win8.1 process you get the successful complete in the dos box but you need to wait ~2 minutes before the dos box closes and then reboot the Classic.  Not sure what is going on during that time if anything. Maybe boB knows!

BTW I believe the usbser.sys files are left in the driver folder when the Win10 is updated from a previous version. But I wouldn't think the new Win10 code would be trying to use it since the new driver is in the local folder.  Another mystery left for those with more knowledge than me.

Most of these windows driver things don't make a lot of sense to me.  As for the waiting 1 or 2 minutes, (it should be 60 seconds), it was a LONG time ago where I saw it work better (IIRC), by waiting that extra minute.  The one minute comes from the timeout in my original windows-side update software.  Someone said at that time (Ryan maybe ?) that if you waited it would work correctly.  Shouldn't be necessary AFAIK but whatever works !  Even I will typically wait that extra minute even nowadays although I'm not sure if it is really necessary.

I am REALLY glad to have Matt around to take over most of this update and windoze 10 stuff !   He's a better man than  I.

"ad hoc, ad loc and quid pro quo so little time so MUCH to know"
(Jeremy, the Nowhere man)

boB

[Matt]

The usbser.sys is still the underlying driver W10 uses to talk to Classic through virtual COM ports. In W10 you get the device driver installation for free with CDC compliant devices (like the Classic). In my previous post, I was merely illustrating how Windows doesn't necessarily care about file versions. In the case of C++ redistribution packages, if it finds the appropriate file name that contains the right function definitions, it will more than likely use the library regardless of the consequences.

Resthome is close to the mark. The reason the MNGP is blank after reboot is because the flash is empty. One of the first things the Classic does during an update is clear the flash for new firmware. My understanding is a little hazy, as I have not looked at the bootloader code, but once the firmware is uploaded and decrypted, the firmware is checked against a checksum. If the checksum does not pass, the firmware is not loaded. But guess what? You still have blank firmware and thus a blank MNGP.

I did not snag the Serial_W32_Lib.dll, I wrote it. The library is a collection of Win32 API calls used to get lower level access to the virtual serial port.

You can actually watch the Classic accept all the packets of data by using the diagnostic console (Control + Alt + c). The last response happens after the last packet is sent. The updater will not finish unless it receives the last response. The last response will not happen if all the bytes have not been received. You can confirm the firmware file by the file name and by number of bytes sent (the MNGP firmware is larger than the Classics).

I would love for someone to come back and say, "Hey Matt! This thing grabbed a random file and pushed it on to my Classic. Or error 10123 happen, Dummy." This is not the case. Most of the time, it just works. This makes it difficult to pin the problem down. My guess is that somewhere between the updater and the Classic a few bits are being flipped that really shouldn't (I call it the Microsoft ether). I'm leaning toward Windows dependency issues (.net, C++ redistribution versions, etc).

You may be glad to know that this problem was seen once (not by myself) in house and subsequently solved by using the installer that Jim Parish developed for the updater. Guess what showed up in an email this morning (this is rhetorical)? Hopefully the installer will be going out into the world shortly. Please forgive my fragments and run-on's.

-Matt