Usb Loader Gx Crashing
Octavis Uberstine
My main menu replacer pops up. I have the load wheel in the corner, but it crashes after a few seconds.
I'm running 1.5...whatever. Not the AE update.
SSE Edit not giving any errors
Loot not giving any errors
Wrye Bash not giving any errors.
MO2 not giving any errors.
Bashed patch is built and active.
No mods were ported wrong (havent installed any ported mods lately).
Worked fine a week ago. I've added mods since then but have disabled the ones I did install - I still crashed.
Loads to the main menu fine when running SKSE loader outside of MO2 (the only things active are my SKSE plugins and a very basic ENB), but crashes when ran inside MO2. Therefore, it's a mod issue, but I can't pinpoint which one it is for the life of me.
.net framework isnt generating any crash logs. No SKSE crash logs or anything either.
*Edit: I should note, no SKSE plugins are enabled outside of MO2, however i have made no changes to installed SKSE plugins since I last played successfully.
Modwat.ch:
Skyrim did update - however I downpatched (it crashed before I updated anyway). Already verified integrity - did not change anything.
Really at a loss here. I have over 300 mods so I'd much rather avoid a full reinstall. Any help?
Hey all, still crashing. Did a full reinstall and put most of my mods back and I'm still crashing at loading the title screen. MO2, LOOT, and SSE Edit are not giving any errors so really honestly at a loss here.
Still running a downpatched version (thats why a CC mod is in the following list), however just to reiterate, it crashed before i updated and downpatched.
Don't know if this helps, but we "found" our SKSE loader executable "had been moved" to our recycle bin. We never did that. We restored it, checked to see it had returned to its cozy place in the folder with its siblings, and the game runs now.
I've never had any problems with the loader, in fact I've been using it for my Teensy++ 2.0 for months.
I plugged in the 2.0's I bought a week ago and now the loader doesn't work for either. Below is a video with this behavior.
It's not a problem with the boards, it's a problem with the software. The boards work perfectly, the cable works perfectly, the drivers are installed and are working properly. The HalfKey works perfectly (on the 2.0, the 2.0++ doesn't function like this).
Win7 Pro x86 on laptop w/ Core2Duo 2GB RAM, using Windows Firewall.
I unzipped the Arduino software, installed Teensyduino on the versions I have.
If you want to look at my config files lemme know which ones to post.
It is not a problem with the boards, it's the software.
It can't be the last sketch I uploaded doing this, I ALREADY SAID I'VE UPLOADED A BUNCH OF DIFFERENT SKETCHES.
If it could be a background application, and you have any idea of how that could be possible, let me know.
I've posted my problem on the PJRC forums, they have alot less traffic than this forum does, and I don't honestly know if it's a problem on the Arduino side, or the Teensy side, so I'm looking in both places.
It is possible that the current application
code on the teensy board is not alive enough to talk to the loader.
Pressing the button is a reset to a bootloader that can talk to the teensy loader program.
This allows the download to happen and should straighten things out again.
But if the code is crashing or locking up, you may have to use the button again.
However once the program reaches the line:
dataiterator = iter(trainloader)
It crashes and asks me twice whether I want to kill the python program(Like I pressed the close window button). The program is then unable to continue and hangs, this problem still persists after changing the:
iter()
to a for loop:
for image, label in trainloader
It always crashes the program. Additionally every time it asks to close it leaves a python3 program running in the background and they each use about 350MB. I am using linux mint 18.1 with a lenovo thinkpad x230. Has anybody come across this error before?
I got a file with a flat data table. I have built a dashboard based on pivot tables & charts. For some reason with the recent addition of some data fields, upon opening the XLSX it shows loading "Data Model".
Yep, it doesn't even crashes, excel just turns off. I already tried disabling all ADD-ins, but still no results.
There was one thing which helped. I restored the excel file 3 days back and it worked fine, but here is the catch. I uploaded that file back to sharepoint and still the same problem happened. The only way for now to use it is Online version
As you said, I think it's a bug
@athalekar
I have this exact same problem. Any fix yet? I found I can upload the file to msteams download then open fine. But if I upload to msteam, then open and use the file then download, then try to open it force closes while loading the data model @eligaliokas any ideas anyone how to fix this? Or what could be wrong? This happened after adding additional columns to a table. And adding charts to a dashboard.
@GGGG670 I cannot figure out why it is crashing as there is no error, no message nor any indication of what is causing a crash. I am not stuck as it is working fine when I open it online as the file is placed in One Drive. I am trying to fix data models, pivot tables and whatnot to check what can fix the crash. So far no luck.
@athalekar I've been having this problem also and over the last few days have tried various remedies mentioned here an elsewhere, and tried different orders or ways of doing things. Here is what finally seems to work for me:
Hi, I just turned on the Event Driven Loader for my project to take advantage of the faster loading times. After I cook and run the game, I get a hard crash upon game startup. The log file says that there are cycle nodes with some UMG widgets. ...
Just make sure that in the player pawn or in some other BP thats definitely used in the game at least one function from any of the BPFunctionLibraries is called, so that the BPFunctionLibraries are definitely packaged.
I did read over the previous question. I wanted to make sure that you were experiencing the same issue. After testing I found that this is working as intended. The issue is that an infinite loop is created and causes an fatal error during packaging. This is not an intended workflow. I hope that this information helps.
Hi Rudy, I think you did not understand the issue. There is no infinite loop in the code itself, its a bug with the event driven loader. If you disable that, packaging works correctly. If you enable blueprint nativization, packaging also works correctly. Only event driver loader enabled and blueprint nativization disabled causes this issue.
After further testing I was able to reproduce this issue on our end (without an infinite loop), I have written up a report and I have submitted it to the developers for further consideration. I have provided a link to the public tracker. Please feel free to use the link provided for future updates.
A year ago I made an external flash loader and that works ( -external-loader/pull/13). I now ported the loader to the STM32H735IG. I use a serial port to print debug messages at certain points. While the flash loader works I do get hardfaults(in the loader, not the application) under certain conditions:
If I connect in STM32CubeProgrammer and then open memory viewer to 0x90000000 and then click disconnect. It doesn't occur when I did not open the memory viewer to 0x90000000 since that doesn't lead to an init of the loader. The flash loader will properly flash the internal and external flash and optionally runs the MCU. So it works, but I do see a hardfault error printed:
So HFSR[31/]DEBUGEVT is active.
And DFSR/Debug Fault Status Register is non-zero. I did not find any documentation about this register for the Cortex-M7. In core_cm7.h I found this means the following bits are set to 1 (and in I found their meaning):
It appears the problem doesn't occur in my application if I initialize OSPI1 before OSPI2. But it still occurs in the flash loader. I found this topic that seems to be related: -mcus-products/stm32-cube-h7-hal-ospim-config-corrupts-previous-port/m-p/126073
Ospi2 is HyperRAM and it is memory mapped. If I initialize OSPI2 first, but do not enable memory mapping the error doesn't occur. So the problem occurs in HAL_OSPIM_Config after OSPI2 is memory mapped. I think a similar thing happens in the flash loader but in this case it is OSPI1 that is memory mapped when the error occurs. HAL_OSPIM_Config doesn't like to be called when at least one OSPI is memory mapped.
HAL_OSPIM_Config does this automatically, but maybe it does it improperly. I will check if I can make some type of fix.
"So I advise you to avoid the OSPIM configuration issue to call HAL_OSPIM_Config only one time at boot."
As far as I know the flash loader doesn't really boot. It is loaded in RAM and then nothing happens. The debugger calls the Init function. The problem is that it does it repeatedly. I'll check if I can modify the Init function.
I'm using 6.10.0. I am not able to download the newer version as the download page keeps crashing.
Edit: I've refactored my init function. I placed global variables (including handles) in no-init RAM. The first time I use memset to zero-initialize these variables and initialize the peripherals. Subsequent calls to init do not re-initialize peripherals. This works perfectly. However the hardfault error still occurs when the debugger disconnects, in STM32CubeIDE when starting a debug session it gets a hardfault after flashing and then starts the application (debugs and runs perfectly), and also in STM32CubeProgrammer after clicking disconnect.
It even occurs if I disable interrupts. I can mask the problem by setting VTOR to 0, but I assume a hardfault still occurs in that case, but it just doesn't call the hardfault handler of the flash loader.