I don't believe it would have anything to do with the loader, unless you were implying that you wish to use a loader to bypass the situation. Does this problem occur on both BIOS and UEFI boot? If so, I'd suggest that it's probably something to do with the Hardware Abstraction Layer and/or the driver itself. The HAL issues would cause these infinite reboot issues. I know recently I uninstalled AMD display drivers and it went into a weird resolution in which I couldn't see the mouse. It was like a low resolution with lots of striping erroring. It's really impossible to describe. My point is that they are potentially doing something with the actual driver package that they shouldn't, and that might be part of the issue you're running into.
Ok, so to respond: These laptops are Pre-UEFI (Though, that is a question of how you look, for example, My laptop only boots Windows via Traditional BIOS, but it does support UEFI in a limited fashion, for HP's recovery tools in my case) so basically the answer of does it occur both ways is Yes, because we have no way to check (and most are BIOS only anyway). As for the HAL... Ill be back later with the results of having people reset their HAL... As for the last line... That is pretty well exactly what they are doing, and because this only effects our subset of laptops, they likely won't help.
I have encountered such a bug myself a few months ago. I called it low resolution "purgatory" mode. The symptoms were quite interesting: The laptop (Intel + AMD / fixed switching mode) would not be happy about having the AMD driver removed. It would be using a VGA driver even whilst Intel HD 3000 was installed! Naturally it should have been using this HD 3000 driver. I assumed that it had some form of virtual display issue but the problem didn't go away through cleaning Intel / the laptop with DDU + manually. Only throwing both drivers on = Intel + AMD would allow the machine to get back to full functionality. -- Maybe this is an indication that AMD really was somehow "moving" these graphics cards into a type of "emulated" dynamic switching position? We are currently stumped on where to look. Would a bootlog be of any good indication of what might be causing this?
There's gotta be something they've been doing differently recently that is causing these weird issues. Perhaps going over older ini files and comparing them with newer ones could shed some light? Here's a random thought... Are people using anti-virus programs on these systems when installing these drivers?
We were just going over the bootlog when we realised that Avast was the last sys file to load. Your intuition could very well be right! The user is on EU time so hopefully we will know by the end of today. Doesn't change that AMD is doing something funky ... I guess we will have to wait and see if the user has success after removing Avast. Personally this is the most interesting stuff I have seen from AMD as moving "every laptop" user to dynamic switching is pretty impressive .. whilst OEMs have locked BIOSes.
When the original 14.4 drivers were released they also included chipset/usb/raid/etc drivers as well. They have now separated the packages. I wonder if it makes a difference which release be used??
To be fair, on these laptops, we don't need the Chipset/usb/raid/etc drivers -all the rest of the hardware is Intel Chipsets, Various USB makers (Renesnas comes to mind), Intel RAID controllers if applicable (because Intel Chipset, and not all laptops support it (mine does)), and as for etc, that is all handled by Windows.
We are out of luck right now with the Avast theory as this situation persists for the user. I am waiting on a second Envy 14 user with the same specs to verify that this is indeed hardware bound.