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 [email protected] 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 [email protected] 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 [email protected] 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 :)