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 <#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 <#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 ***@***.***> 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 <#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.

[dovecode]

@enricoturri1966 any update on works on this issue? It seems that many people can reproduce it, so debugging it should be possible...

[c2technology]

Can confirm this still exists in PrusaSlicer-2.3.3+win64-202107161027

Updating the ini file moves it back to primary screen, solving the problem.

A "simple" fix could be to validate the values of window_mainframe when retrieving it, any negative values could be set to 0:

PrusaSlicer/src/slic3r/GUI/GUI_App.cpp

Line 860 in b80fb40

if (app_config->has("window_mainframe")) {

Edit: When testing on third monitor (to the right of main monitor), the problem is reintroduced, but without negative values in the ini file. Not familiar with C++, but if you could get the primary monitor dimensions and check the rect against the monitors size, if it's out of spec, reset to 0?

[bubnikv]

As usual, multiple different issues are mixed here:

1. The initial issue was caused by the AMHook.dll of InnoCielo Meridian. We will blacklist AMHook.dll in PrusaSlicer, so you will get a message box when starting PrusaSlicer that this hook DLL was injected.

2. There may be an issue when starting PrusaSlicer that was closed on a secondary display after the secondary display was disconnected, thus its coordinates stored in PrusaSlicer.ini are negative and something in one's Windows installation does not like it. Currently PrusaSlicer calls Win32 API MoveWindow() to these negative coordinates first, then it may call another MoveWindow() call to fix the position. Maybe something (the OpenGL driver?) crashes at the first MoveWindow(). We may try to improve on that.

3. The OpenGL driver may not survive opening PrusaSlicer on secondary monitor. We cannot do much about that. We may allow one to force opening PrusaSlicer on primary monitor only through a new key in PrusaSlicer.ini, but that key would have to be edited manually by the user if PrusaSlicer does not start at all.

[bubnikv]

@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.

If that happens, is the Preferences dialog still accessible?

[bubnikv]

@quarky42 your issue is completely different from the others. Please don't mix issues, please open a new one.

[bubnikv]

@quarky42

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.
...

Please enlighten us. What is a "lockable drive"? Is it a Windows 10 feature?

[YuSanka]

Maybe crazy idea... But what will happen if you suppress to show splash screen in Preferences?

[bubnikv]

@c2technology

When testing on third monitor (to the right of main monitor), the problem is reintroduced, but without negative values in the ini file. Not familiar with C++, but if you could get the primary monitor dimensions and check the rect against the monitors size, if it's out of spec, reset to 0?

First, negative coordinates are perfectly fine if your secondary monitor was left from the primary monitor. We tested that and everything works fine on our setup.

Second, if you happen to close PrusaSlicer on secondary monitor, disconnect the secondary monitor and start PrusaSlicer, it moves the window to the negative coordinates first, then it "sanitizes" the window coordinates and moves the window the second time. We may improve on that, but frankly it seems to me that the majority of issues you are guys having are connected to the OpenGL driver that does not like the OpenGL window to be either created on a secondary monitor or to be created on primary monitor and later moved to the secondary monitor.

[kocikdav]

@TNgineering can I ask you to try this build on computer where PrusaSlicer is not whitelisted in Blue Cielo software you mentioned? During startup, you should get warning message about AMHook.dll being loaded. Please let us know if the message displays and what is the content. Thanks!

[chriseich]

PrusaSlicer 2.3.3:
Same Problem Slicer crashes with second monitor on the left side. Changing the setting in PrusaSlicer.ini for "window_mainframe" into a positiv value, everything work fine.

[quarky42]

@quarky42

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.
...

Please enlighten us. What is a "lockable drive"? Is it a Windows 10 feature?

@bubnikv

Go read up on Bitlocker, introduced in January 2007 and enlighten yourself on technology that is now almost 15 years old. I chose that wording to indicate that the state of the drive could be locked. The drive letter is present, but the partition isn't mounted because the drive is still locked until the key has been entered. I'm sorry this wasn't more clear. If you had simply asked me to elaborate instead of getting sarcastic with me, I would have gladly explained over a year and a half later.

While you're looking up Bitlocker, you can lookup the word pedantic, as well. There is no need to be rude, elitist, or short tempered with people that are trying share information. Are you here to help? Do you think I'm here to make your life more difficult or am I trying to help? You can disagree with me without being snide.

The program freezing on load happened to me in both situations: dual monitors and later because the drive that the referenced image file was locked. I also had dual monitors back then. So, instead of reporting the program freeze as a separate thread, I looked this one up...I saw that it had been reported and left it at that and didn't duplicate an already reported issue. Shortly afterwards, I discovered a new way to have the same problem and decided to share that information because as a software developer myself, I realize it is possible to have the same kind of issue (program freeze on startup) for new reasons. The root cause of both issues points to bad assumptions being made and a lack of condition checking going on in both cases.

It's not my fault that PrusaSlic3r doesn't do an appropriate amount of error checking before it tries to reference display coordinates that don't exist or it tries to open files that it can't read. That's why try/catch blocks exist in the first place. It's why when something you expect to succeed still has a decent default behavior when it fails instead of the program freezing. Lookup graceful degradation.

That level of error checking / condition handling is learned by highschool students and college freshmen.

Really it is the same root cause: failing to check inputs and assuming that they are good during application load up without proper error handling and without graceful degradation. It doesn't really matter that one is because of bad saved coordinates (probably due to a difference in coordinate systems or more likely allowing bad coordinate data to be saved in the first place by not checking the correct monitor on close because of yet another faulty assumption) and the other one is a bad assumption that an image file that was loaded previously must always be there and couldn't possibly be temporarily unreachable.

If you have the right perspective, then finding other areas where bad assumptions are made becomes a lot easier. First you have to recognize the pattern though.

[lapo-luchini]

I got a different "freeze on startup" too:

This is console output (I also tried with --sw-renderer, same result):

C:\ProgramData\chocolatey\lib\prusaslicer\tools\PrusaSlicer-2.3.3+win64-202107161027> prusa-slicer-console.exe --loglevel=5
[2021-10-14 20:23:44.226326] [0x000076e8] [debug]   full path: 10428350711846301167
[2021-10-14 20:23:44.227304] [0x000076e8] [debug]   single instance: undefined. other params: prusa-slicer-console.exe;--loglevel=5
[2021-10-14 20:23:44.228280] [0x000076e8] [debug]   init wx instance checker 10428350711846301167.lock C:\Users\lapo\AppData\Roaming\PrusaSlicer/cache/
[2021-10-14 20:23:44.228280] [0x000076e8] [info]    instance check: Another instance not found or single-instance not set.
[2021-10-14 20:23:44.235121] [0x000076e8] [debug]   boost::filesystem::permisions before copy error message (this could be irrelevant message based on file system): The system cannot find the file specified
[2021-10-14 20:23:44.296682] [0x000076e8] [info]    Checking if indices need to be installed from resources...
[2021-10-14 20:23:44.302543] [0x000076e8] [trace]   Best translation language detected (may be different from user locales): en_GB
[2021-10-14 20:23:44.302543] [0x000076e8] [trace]   Switching wxLocales to en_GB
[2021-10-14 20:23:44.978529] [0x000076e8] [debug]   boost::filesystem::permisions before copy error message (this could be irrelevant message based on file system): The system cannot find the file specified

I tried deleting the "cache" folder and it gets populated again (and then freezes anyways).

I tried with Process Monitor, but I didn't see anything suspicious near the end of the log.

I also tried re-installing from scratch.

What else can I try to get back to use the software?

[bubnikv]

@lapo-luchini
Could you please try https://github.com/prusa3d/PrusaSlicer/releases/tag/version_2.4.0-alpha3
The new alpha checks for some rough applications which inject their DLLs into our process.

[lapo-luchini]

@bubnikv sorry, I can't reproduce anymore… upgrading other pieces of software probably changes something. :(

[lukasmatena]

We tried to workaround this problem in upcoming 2.4.1 release by making the position restoring optional (and on by default). When the crash described here occurs, PrusaSlicer will suggest to turn the feature off on the next start. It is not exactly a fix, but it is better than nothing.

Because we cannot reproduce the issue, could you guys please test the following build and let us know if it helped?
https://prusaslicer:slicer@slicerbuilds.prusa3d.com/files/lm/PrusaSlicer-2.4.1-alpha0+4-win64-g200cbd165-202201141630.zip
If the download requires login use login: prusaslicer password: slicer.

If the build crashes on the very first try, run it again. Thanks a lot.

[n8bot]

@lukasmatena just FYI, I've had the new window position crash dialog appear at startup several times, and afaik none of them had to do with the window position problem (I have a single monitor, the crash is always unrelated, or merely stopping debugging forcefully from VS can bring that dialog on next startup).

So, the dialog might end up appearing more than intended and confusing users.

[lukasmatena]

@n8bot Good point, thanks. @YuSanka will take care of it.

[lukasmatena]

Do you still have this issue with 2.6.0-alpha3?

[lukasmatena]

No response, closing. There is a good chance that the changes in 2.6 series fixed this.