[G3 General] topet2k12001:
Hi @Pannam,

Thanks for your response.

For Item #1: It can be a case as difficult as a driver issue (for your Windows 7 32-bit machine). It's possible that ADB can detect it, but I believe that LG drivers are still needed. Or it's possible that your Windows 7 machine uses the generic/universal drivers and not the one for LG. I can't make a conclusion at this point though because I'm running a 64-bit Windows OS. Best way for me to troubleshoot is to replicate the issue you reported by mirroring your setup, so please allow me time to have a 32-bit OS installed on my machine (I'll just dual-boot). If it's not too much to ask: can you plug your LG G3 (turned on to normal Android OS) and open Device Manager, and then take a sceenshot?

Or it could be a case as simple as using a different USB port or USB cable. I have a USB cable for Nexus 5 which is old and loose; sometimes I encounter the issue you are describing because of this. I eliminated this issue when I used the standard/official USB cable that came with my LG G3. In another instance, plugging to another USB port solved that issue for me.

Or...it is possible that you may need to "revoke USB debugging authorizations" from the LG G3 before plugging again to a different machine? I haven't tried plugging my LG G3 to a different machine (after already enabling USB Debugging and authorizing it on my machine) so I don't know if this has something to do with it. Conversely speaking, the first time you enabled USB debugging and then the first time you plugged it to another machine, it's possible that the "Authorize this computer" message has popped-up on your LG G3 and might not have "Accepted" it until the message box timed out.

By the way, I coded/programmed ImageprepGUI using a 64-bit OS (Windows 8), but it was built/compiled for x86 (32-bit).

For Item #2: when reading the script's output (Device found in COM...), do you see a port number (there should be a number beside "COM")? Can you also run the "reg query" command that I asked @ravi.vydianathan to run (just plug the LG G3 into a USB port, open a DOS box, and type or copy-paste the command)...it should produce a text file named "com.txt"; please share a copy so I can look into it. Please do this on the machine you intend to run ImageprepGUI.

Although, even with other one-click/automated rooting tools that came out prior to ImageprepGUI, this is a common issue that's why other one-click/automated rooting tools also have a reminder/prompt for end-users to boot their device manually into Download Mode. Where ImageprepGUI probably differs is the time interval of "wait" before it continues with the script. I'll look into extending the timer or the "wait" in order to allow end-users enough time to manually reboot. Or, I'll add a "pause" to the command-line portion of the script so that it will wait until it detects the LG G3 in Downlaod Mode and will not continue until the end-user presses something on the keyboard.

In my tests, I did encounter a few instances when Imageprep (whether in command-line form, or in GUI form) will say that the "device is found in COM..." without the port number. I tried to replicate (even before you reported these items) and noticed that this is caused by manually "leaving" download mode via the command line, after having entered Download Mode via Imageprep...another is when I exited Download Mode "abnormally" from the command-line (either by pressing Ctrl+C or forcibly exiting the command line running the "Send_Command" via the "X" button or via Task Manager). Another is when I entered Download mode via ImageprepGUI (essentially the GUI is just a front-end for the command line), and then I opened another command-line and exited Download Mode via that second instance of command line. Have you tried rebooting the machine and running only ImageprepGUI after reboot (e.g. don't re-run ImageprepGUI immediately after a failed attempt)?

For Item #3: Actually, ImageprepGUI currently has those lines of code (commands) for the automation part that intend to keep the active window on top (you might have even noticed that ImageprepGUI will automatically attempt to minimize all other windows prior to the automation). As I am new to programming, I will figure out where to best place those pieces of programming code to keep the desired window on top. Alternatively, I'm looking at pre-packaging ImageprepGUI with the already-extracted image files although I purposely went away from this direction, because:

1. I want to give end-users the option of extracting the image files from their preferred firmware, and not the ones that will come from me

2. Anticipated up-keep needed to maintain different ImageprepGUI files just to pre-pack them with image files from the latest firmware versions of each and every LG G3 variant/model available out there

In the meantime, please make sure to minimize all other windows when running ImageprepGUI. This is why I implemented a pop-up message box (which prompts the user to read and click "OK") that will hopefully remind end-users to minimize all windows (and temporarily turn off other apps that may cause other windows to appear/pop-up). I understand that not all end-users will read it though, so I'm working on that piece to make it ultimately fool-proof.

For Item #4: that's variable since you rooted manually, so it might be difficult for me to troubleshoot. When "it freezes at the LG Logo Screen", what is the color pattern of the LED light? I did encounter something similar when I was testing while I was building ImageprepGUI and in my case it was just flashing green and blue and doesn't stop until I turn it off (and I will have to do a full reflash to fix). I found out that this was caused by a half-baked rooting attempt (which can be related to your Item #1 and #2, where the rooting script finished but in reality the device was not properly rooted).

For the Log: that piece is merely for TWRP installation and "bumping" (patching or signing) of boot.img. This part of ImageprepGUI is after the device being rooted. Looking at the logs, everything went as intended (please disregard the errors for mkdir - it simply means that it wasn't able to create the desired directories for copy-pasting the backup image files...I can easily fix that and it doesn't have any impact/relationship to the issues you mentioned). I can even see that the "printf" issue has been solved, because Busybox got installed (or rather, symlinked) properly.

So it means that your boot.img got "bumped" properly. If you are not confident that ImageprepGUI was able to "bump" your boot.img properly: at the end of the script for TWRP installation, it will reboot your device to TWRP Recovery. Flash the Sharpening Script Mod by [MENTION=2174433]Skin1980[/MENTION], because it does include "bumping" (again) of boot.img. Then exit the Sharpening Script Mod...UNCHECK "reboot now" from the Script Mod and use TWRP's "Reboot" instead. Therefore, if you still see the device being stuck at the LG Logo, then we can ascertain that the problem was due to the "improper/incomplete" rooting that I have mentioned above.

In summary: at this point it leads me to believe that (based on the issues you pointed out) I just need to address the following:

1. Timing/pausing for Download Mode (other, slower machines may need more timeout - or a "pause" can solve it)

2. Test ImageprepGUI on a 32-bit system (I'll try Windows 7 to mirror your setup) to verify your issue of a different machine not detecting the device (although other users have not encountered your issue - we can ask though if someone else with a 32-bit Windows OS did not encounter the issue)

3. Keep active window on top (for the automation part of extracting image files). In the meantime, end-users will need to minimize all other windows manually as well as to avoid using other software/apps that can produce window pop-ups that will interfere with the automation.