PrusaSlic3r freezing at startup (Win 10)

[samuelcanadi]

Version

PrusaSlicer-2.1.0+win64-201909160915

Operating system type + version

Windows 10 Build 18362

Behavior

• Describe the problem If I want to start PrucaSlic3er, the window opens but than it freezes immediately. This occurs with all versions I tried. It's only on this single machine.

• Steps needed to reproduce the problem Execute prusa-slicer.exe

• Expected Results PrusaSlic3r starting and ready to open files.

• Actual Results Freezing window without rendering. Cursor is a "loading icon".

  • Screenshots from PrusaSlicer preview are preferred

[Jebtrix]

Did you try renaming/removing existing profile folder c:\users\username\appdata\roaming\prusaslicer?

[samuelcanadi]

If I rename the folder, the error still occurs and a new folder is created.

[Jebtrix]

Well that rules that out at least. If its a OpenGL/GPU issue, besides trying the usual install latest drivers you may want to post your particular GPU information. You can use OpenGL Extensions Viewer to create and post a GL Report (simple txt file). You can also perform rendering tests with different versions of OpenGL with it as a sanity check.

http://realtech-vr.com/admin/glview

Other than that devs will have to pick this one up.

[samuelcanadi]

I have a GTX1080 with the latest driver.

GL report glreport.txt

[Jebtrix]

Did the render tests display OK?

[samuelcanadi]

The tests from 3.0 up to 4.5 are passed. Also 1.1 up to 2.1. If i start the test without acceleration OpenGL Extension Viewer crashes.

[Jebtrix]

If i start the test without acceleration OpenGL Extension Viewer crashes.

Yeah it tends to do that without acceleration so for all intensive purposes your GL report looks normal for Nvidia. Identical to my working machine besides specific model.

Did PrusaSlicer v2.0 work? You can try some pre-2.1 versions at https://github.com/prusa3d/PrusaSlicer/releases to see if that makes any difference and pinpoint what version a problem was introduced. Otherwise I'm out of ideas to narrow down anything more for the devs.

[samuelcanadi]

No, v2.0 doesn't work too. v1.42.1 crashes. And even (original) Slic3r crashes.

Are there any logs to review to execution?

[Jebtrix]

Wow.. Win10 showing you some loving. At least with the crashing you should get some crash reports in windows event viewer. Can you find one and post details on one. It may or may not help. Getting process minidumps on windows requires the program to actually implement the functionality so we can only go so far. I just noticed your OS build number, are you on an insider ring build of windows?

[bubnikv]

You may try to run prusa-slicer-console.exe --sw-renderer --loglevel=5 from the console. This will show some debugging information on the command line and it will also use the bundled software rendering OpenGL library MESA. It will render slowly, but it should run.

I am afraid, that without access to your computer we will not come much further, especially if PrusaSlicer 2.0 and Slic3r PE 1.42.1 crash as well. I suppose the OpenGL driver is guilty, but I may be wrong.

[samuelcanadi]

I just noticed your OS build number, are you on an insider ring build of windows?

No, only common updates.

You may try to run prusa-slicer-console.exe --sw-renderer --loglevel=5 from the console. This will show some debugging information on the command line and it will also use the bundled software rendering OpenGL library MESA. It will render slowly, but it should run.

I will try that tonight.

I am afraid, that without access to your computer we will not come much further, especially if PrusaSlicer 2.0 and Slic3r PE 1.42.1 crash as well. I suppose the OpenGL driver is guilty, but I may be wrong.

I guess it's the OpenGL driver, too. Is there a way to reset OpenGL completely in Windows? The nvidia driver updates didn't do it.

[bubnikv]

Is there a way to reset OpenGL completely in Windows? The nvidia driver updates didn't do it. Sorry, but OpenGL completely in hardware vendor hands on Windows.

st 18. 9. 2019 v 9:51 odesílatel samuelcanadi notifications@github.com napsal:

I just noticed your OS build number, are you on an insider ring build of windows?

No, only common updates.

You may try to run prusa-slicer-console.exe --sw-renderer --loglevel=5 from the console. This will show some debugging information on the command line and it will also use the bundled software rendering OpenGL library MESA. It will render slowly, but it should run.

I will try that tonight.

I am afraid, that without access to your computer we will not come much further, especially if PrusaSlicer 2.0 and Slic3r PE 1.42.1 crash as well. I suppose the OpenGL driver is guilty, but I may be wrong.

I guess it's the OpenGL driver, too. Is there a way to reset OpenGL completely in Windows? The nvidia driver updates didn't do it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2939?email_source=notifications&email_token=ABMPSI4FG24O7TOIBLBD6QLQKHMYBA5CNFSM4IXTBRD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD67E3WY#issuecomment-532565467, or mute the thread https://github.com/notifications/unsubscribe-auth/ABMPSIZLIC5RHZOJO4XVHULQKHMYBANCNFSM4IXTBRDQ .

[Jebtrix]

I guess it's the OpenGL driver, too. Is there a way to reset OpenGL completely in Windows? The nvidia driver updates didn't do it.

Have you tried an older Nvidia driver version? You can try DDU to completely remove nvidia drivers to start over. Make sure you follow all recommended steps to use. https://www.guru3d.com/files-details/display-driver-uninstaller-download.html

[samuelcanadi]

You may try to run prusa-slicer-console.exe --sw-renderer --loglevel=5 from the console. This will show some debugging information on the command line and it will also use the bundled software rendering OpenGL library MESA. It will render slowly, but it should run.

If I run your command, Prusa Slicer starts and can be used. Thank you.

Have you tried an older Nvidia driver version? You can try DDU to completely remove nvidia drivers to start over. Make sure you follow all recommended steps to use. https://www.guru3d.com/files-details/display-driver-uninstaller-download.html

I will try a complete reinstall of the nvidia driver the next few days.

[bubnikv]

prusa-slicer-console.exe --sw-renderer --loglevel=5

You may switch permanently to the software renderer by copying the MESA/OpenGL.dll one level up next to prusa-slicer.exe. Though software rendering will be slow, especially in the 3d print path preview.

st 18. 9. 2019 v 22:05 odesílatel samuelcanadi notifications@github.com napsal:

You may try to run prusa-slicer-console.exe --sw-renderer --loglevel=5 from the console. This will show some debugging information on the command line and it will also use the bundled software rendering OpenGL library MESA. It will render slowly, but it should run.

If I run your command, Prusa Slicer starts and can be used. Thank you.

Have you tried an older Nvidia driver version? You can try DDU to completely remove nvidia drivers to start over. Make sure you follow all recommended steps to use.

https://www.guru3d.com/files-details/display-driver-uninstaller-download.html

I will try a complete reinstall of the nvidia driver the next few days.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2939?email_source=notifications&email_token=ABMPSIZRI2KW7UZQ42ORFYDQKKCYHA5CNFSM4IXTBRD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7BI74Q#issuecomment-532844530, or mute the thread https://github.com/notifications/unsubscribe-auth/ABMPSI5245M6ZVDEKOOO5Q3QKKCYHANCNFSM4IXTBRDQ .

[TNgineering]

I'm getting the following message from Visual Studio's debugging: "Unhandled exception at 0x00007FFC0E9C8DDB (AMHook.dll) in prusa-slicer.exe: 0xC000041D: An unhandled exception was encountered during a user callback."

[bubnikv]

https://www.dlubal.com/en/support-and-learning/support/faq/002448

The crash has occurred in the AMHook.dll. This DLL is part of InnoCielo Meridian. Contact your administrator to customize InnoCielo Meridian's settings.

[TNgineering]

Hello Vojtech,

Would you be interested in setting up a team viewer session? I'm currently trying to rerun the alpha2 version in the standalone folder.

Thanks, Thomas

On Wed, Jan 22, 2020 at 2:05 AM Vojtěch Bubník notifications@github.com wrote:

https://www.dlubal.com/en/support-and-learning/support/faq/002448

The crash has occurred in the AMHook.dll. This DLL is part of InnoCielo Meridian. Contact your administrator to customize InnoCielo Meridian's settings.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2939?email_source=notifications&email_token=AGYFEPJK2SCKHDDXNIU7MULQ6743HA5CNFSM4IXTBRD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJSS2RY#issuecomment-577056071, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGYFEPNWHZKQOBGJ6EU44RTQ6743HANCNFSM4IXTBRDQ .

-- Thomas D. Neff Mechanical Engineer University of Illinois, Urbana-Champaign Engineering Mechanics, Class of 2010 Ph. 815.910.3942

[bubnikv]

@TNgineering

The crash has occurred in the AMHook.dll. This DLL is part of InnoCielo Meridian.

I don't think that remoting to your box would help, if the crash is indicated in a 3rd party application, which hooks into our lovely slicer and messes is up.

[TNgineering]

Do you think you have a way to prevent the 3rd party hook? I'm pretty sure that this is being caused by my company's Meridian Software but is there any work around for the AMHook?

Thanks, Thomas

[TNgineering]

OMG I finally figured it out. Blue Cielo has this "Application Integration" program that autoloads at startup and basically inspects every menu bar and checks to see if it needs to do something. I'm sure the combination of not having admin privileges and not officially installing Prusaslicer.exe was part of the problem. There ended up being a way to whitelist the Prusaslicer.exe from within the Application Integration program and now everything works.

[bubnikv]

Thanks for heads up. I will let our support and content guys know.

[RogueProeliator]

I have found at least one other cause of this crash and it is reproducible... On Windows 10 with both the 2.1.1 release and the latest 2.2 RC, if I close the Prusa Slicer on my left monitor (i.e. left of the primary Windows monitor), the PrusaSlicer.ini file is saved with a value such as: window_mainframe = -1927; 2; 1932; 1165; 0 I then experience the exact same issue described herein. Removal of the AppData profile, obviously, fixed this as suggested early on in this thread. However, I have been able to change that INI value to something such as: window_mainframe = 0; 0; 1936; 1176; 1 (Main thing being the first two values set to 0)

Thus far it has "recovered" from the freeze at least 3 times in a row.

[bubnikv]

thanks for info. Due to COVID19 we are all home bound now, I suppose nobody has a dual monitor at home to test, so we have to postpone it.

[muhmuhhum]

if it helps i have the same problem and the fix from @RogueProeliator helps to get it back to running. I have the same values in the PrusaSlicer.ini as him.

[bubnikv]

There is a function

void GUI_App::window_pos_sanitize(wxTopLevelWindow* window)

in GUI_App.cpp:1125

that shall fix this. We shall fix this issue once we can reproduce it.

[samuelcanadi]

I have found at least one other cause of this crash and it is reproducible... On Windows 10 with both the 2.1.1 release and the latest 2.2 RC, if I close the Prusa Slicer on my left monitor (i.e. left of the primary Windows monitor), the PrusaSlicer.ini file is saved with a value such as: window_mainframe = -1927; 2; 1932; 1165; 0

Solved the problem for me. Right screen is a problem too. PrusaSlicer starts only when it was closed on the main screen before.

[dovecode]

It looks like this happens on Windows 10 whenever PrusaSlicer.ini points to a screen different from the primary monitor. I think it is also related to Windows or GPU driver versions, as this started to happen to me for the Android Virtual Devices sometime in the last few weeks, too.

Fwiw, until there's a fix, I'm using a small sed script to fix up the ini file. Adding here in case it is useful for others (no warranty, use at your own risk, etc, etc). It replaces the (x,y) position with zeroes if it detects a negative or four-digit x-coordinate:

sed -i 's/\(window_mainframe = \)\(-[0-9]*\|[0-9]\{4,\}\); [0-9]*; \(.*\)$/\10; 0; \3/' USER_HOME/AppData/Roaming/PrusaSlicer/PrusaSlicer.ini

Sub in your user dir for USER_HOME above.

I tried to set up the dev env to take a crack at a fix, but the setup on Windows at least is a bit too much.

[enricoturri1966]

@RogueProeliator, @samuelcanadi, @dovecode

As mentioned by @bubnikv I do not have access to an external monitor right now, so I cannot try to reproduce this issue. I have some suspects about OpenGL context creation which may lead to an invalid context, but this is just speculation, at this stage. Is PrusaSlicer "freezing" on the same monitor where it was closed ? If you disconnect the monitor, and restart PrusaSlicer, the application should move back to the main monitor. Is this working or this is also "freezing" ?

[dovecode]

Yes, this happens when you close PrusaSlicer from a secondary (i.e. not the one marked in Windows as the primary) monitor. It opens on the location it was closed (secondary monitor), but the UI never fully renders, just what @samuelcanadi posted initially.

I haven't tried to physically disconnect the monitor, but if I change the multimonitor setup to be "Duplicate Displays" instead of "Extend Displays" and restart PrusaSlicer, it relocates to the only monitor available and works, even after a restart and after re-enabling "Extend Displays".

However, if I then move PrusaSlicer to secondary, close and then re-open, the same behavior is seen.

Basically, it looks like it freezes if the first tuple in window_mainframe in PrusaSlicer.ini is outside the main monitor's area. I've tried with both having main monitor to the left (so window_mainframe's x-coordinate is larger than the right-most of the main monitor) and to right of the secondary (which makes window_mainframe's x-coordinate negative).

Let me know if there's any debugging I can do on my side, as I can consistently reproduce the problem. What I can't seem to figure out, though, is how to configure the PrusaSlicer dev env on Windows :)

[enricoturri1966]

@RogueProeliator, @samuelcanadi, @dovecode Could you please test if the attached experimental build helps in fixing this issue ?

https://www.dropbox.com/s/2bs298fkd3hvhi9/PrusaSlicer-2.2.0%2B108-et-bug-fixes-win64-gf94e3ef22-202004070637.zip?dl=0

[dovecode]

Unfortunately, this build behaves the same. Works on primary, but hangs on secondary...

Shame, as I was thinking along the same lines after googling a bit of "OpenGL hangs on secondary monitor". Looks like it's a known issue as each monitor is its own context. However, I'm confused as how PrusaSlicer still works fine within the same session (I can render the build plate fine across two monitors...)

[enricoturri1966]

I made some tests by connecting my TV to my laptop:

Operating System: Windows System Architecture: 64 bit Windows Version: Windows 10 (build 18362), 64-bit edition Total RAM size [MB]: 17,099MB OpenGL installation GL version: 4.6.0 NVIDIA 399.24 Vendor: NVIDIA Corporation Renderer: GeForce GTX 1060/PCIe/SSE2 GLSL version: 4.60 NVIDIA

I have tried all the combinations I could imagine, as: which monitor use as primary/secondary, left/right position, resolution and font scaling, vsync on/off. PrusaSlicer always worked fine for me. I also saw on Internet that similar issues are reported for many other applications, so I am afraid that this is something that has to do with the graphic card driver :(

Do you guys have a single graphic card installed or you have integrated+dedicated setup ?

[dovecode]

I think you're right, as I also saw it with the Android virtual device manager. There I fixed it by changing renderer, though. Since it started happening in the last few weeks, I suspect it is related to a device driver version, most likely nVidia's.

My data (collected from dxdiag and OpenGL Extension Viewer): Operating System: Windows 10 Pro 64-bit (10.0, Build 18363) (18362.19h1_release.190318-1202) Memory: 32768MB RAM GPU: GeForce GTX 970, VRAM 4GB (well... sort of ;) OpenGL: 4.6.0 NVIDIA 445.75

~Over the next few days, I'll try to experiment with older drivers to see where it broke.~

I've tried a number of older nVidia drivers, going all the way back to 399.24 that @enricoturri1966 reportedly had it working on and still no luck. I've also tried the 2.1.1 release of PrusaSlicer with the same results

Driver versions tested (each time uninstalled the old with DDU):

• 445.75
• 442.74
• 442.50
• 442.19
• 441.87
• 441.66
• 430.64
• 399.24

I'm not quite sure what to try at this point...

[RogueProeliator]

FWIW, mine that is crashing is an AMD graphics card. I will try the experimental build just to see even though it did not fix @dovecode's install.

Perhaps it is a Windows 10 version/update issue instead of a graphics driver issue (or a combination of Windows revision with specific driver versions). However, given it is happening on both AMD and nVidia, seems that would indicate Windows to be the common denominator.

[langillerr]

For me this happens when you when you have it opening in negative window space. If your furthest left monitor is not your 'primary desktop' in windows, it immediately crashes after opening to a white page.

To reproduce (tried on two different PCs), setup two monitors side by side and make the right one the "primary desktop" and then open PrusaSlicer. If you move it to the left screen, close it, and then reopen it (remembers window position) then it will crash on startup.

This is also an issue in the vertical as well. With my quad stack monitors if one of the upper two is primary, it crashes when opening on the lowers.

[dovecode]

@langillerr this is what I found when trying different configurations: Anytime PrusaSlicer has a startup coordinate outside the primary monitor (whether that's left, right, above, or below), it freezes like this during startup.

[langillerr]

Wow, fast reply! Also, I just tried this, and it's working on my screen so long as I have it in the 'positive space' of the windows. Think of it as an X/Y graph with 0/0 being the bottom left of your primary display. i.e. two 1080p screens, it still opens at X=1100

[dovecode]

Hmm... interesting. My screens are 4K. Maybe that's why I also see the problem with screens to the right of primary? A screen to the right of my primary would start at X=2560 rather than ~1080~ 1920.

[langillerr]

Let me try - I've got two 4Ks that I disconnected to test.

Update: With 4k, I see it on all screens other than the primary. Best way to fix it is to make the screen it's trying to open up on primary display, and then move it to where you want it to open, and revert your primary display back.

[dovecode]

Hmm... no... I tried with resolution of 1920x1080 on both displays and I see the same problem: Anything outside of primary display crashes.

[langillerr]

Weird. So what's the variable then?

I'm running 2x 1080p and 2x 4k screen 1080ti with latest drivers windows 10 build 1909 (fresh install within the last 2 weeks)
latest PrusaSlicer mainline (just checked for updates)

[dovecode]

I can't explain why I see the problem with positive coordinates while you don't, but I think @RogueProeliator is on to something. It is not likely to (just) be a display driver issue, but related to Windows updates. It is too late for me to try to back out of my latest Windows patch, so I don't see a way to try to get to @enricoturri1966's Windows level...

[dovecode]

Just tried the latest nvidia driver (445.87) and the problem persists

[quarky42]

The latest version downloaded directly from Prusa website installed today (v2.2) on Windows 10 crashes within seconds of trying to load it the second time I tried using the program (after a system reboot). Nothing displayed on the screen, just waiting for it to load and then notification from Windows that the program has crashed.

I looked at the PrusaSlicer.ini file and I can see that it is referencing a last_output_path as well as config_directory and skein_directory that are all on a drive that is locked on boot until I manually unlock it. I've tried many times to launch it up the this point. I only realized after I started looking that I hadn't unlocked that drive. I tried unlocking the drive and launching the program and it got a lot further but still crashed.

After I unlock my drive and try to launch the slicer as my regular user account, the whole GUI loads, I can see the build plate and all the menu bars. I can see that the printer settings have loaded, but the program still crashes before I can interact with it; it has clearly gotten further in the load process.

If I launch the program as an administrator (which is a completely different account) then the slicer comes up normally but it has nothing setup as everything was setup under my regular user level account.

I deleted the PrusaSlicer directory from my user profile\AppData\Roaming directory. Now the program loads up and lets me enter in everything manually again. After the wizard completes, I seem to be able to use it. I closed the program and reopened it, and it seems to be fine.

During the wizard, I did load a PNG texture for the bed and a STL file for the model of the printer that are on that lockable drive. I assumed that the program would import those files and cache them locally within the profile of the application. After observing the crashing behavior though, I now assume that the program does not cache those files and that when it tried to load with the drives locked there was no check to see if those files were accessible and the program crashed with some sort of file access violation.

To test this further, I went ahead and manually locked the drive, tried to open Prusa Slicer and was met with a delay and then immediate PrusaSlicer has stopped working message. (No GUI).

I unlocked the drive and launched PrusaSlicer one more time. Now I am able to use it without crashing, so I am seeing two bugs here. 1> PrusaSlicer allows the selection of files during printer setup that may not be available later and this is leading to crashes on load when the application can no longer access those files. The files chosen during setup should be copied to the user profile and cached there. This is common behavior for applications using external files as part of their internal setup.

2> I am seeing a second bug where after using the program for a while, saving gcode, saving a project file, and closing the application, rebooting, something is left behind that is crashing the application. I did save my roaming PrusaSlicer profile directory before I deleted it, so I can upload it if someone wants to review it.

I was able to repeat bug #1 readily, just by locking the drive that the printer's texture and model files were selected. I have not fully figured out what has caused bug #2, but I suspect that it is related to bug #1.

So in the meantime I will manually copy those two files over to the Prusa Slicer User Profile directory so that it is always available. That is an okay workaround, but I would still recommend that this be handled automatically when the files are selected. Also, if the program is going to try and access any files or paths on load, then it should be checking whether those files exist first and if they can be opened without crashing. If a file used on a previous run can't be opened, it should be noted to the user, skipped, and the GUI should open to a default state.

[Flashyghost]

Idk if this will help anyone but i had this issue after adding a custom bed mesh and texture. I couldn't open the app without it crashing, I just went into the appdata and deleted the mesh and texture files and it was fixed.

[philipphagen87]

Can you post the whole path of the appdata? Thanks, phil

[dovecode]

@Flashyghost, I have never added a custom bed mesh or texture, so that would appear to be a different issue than the secondary monitor issue, which is easily reproducible by changing the coordinates in the settings file.

@philipphagen87, the configuration is in PrusaSlicer.ini in %APPDATA%\PrusaSlicer in Windows.

[pfschuyler]

I had the exact same issue and it was related to multiple monitors. If you have multiple monitors, Try going into your NVIDIA control panel and changing the primary monitor to a different monitor. You can do this by selecting the monitor>right clicking>make primary. Then launch the slicer. No clue why this happens but its only the occasional thing, but this seems to fix it.

[dovecode]

Yes. Changing the primary monitor to the one where PrusaSlicer starts on will allow PrusaSlicer to start.

Moving PrusaSlicer to the secondary and then closing PrusaSlicer will then make the problem resurface.

It is not a solution. It's a very temporary workaround.

Btw, there is no need to involve NVIDIA control panel in changing primary monitor.