Jump to content

Control Eng

Dormant
  • Posts

    4
  • Joined

  • Last visited

Everything posted by Control Eng

  1. I cannot see any dll errors in your log (other than the ones that exist in running Cura logs). In my opinion your crash looks similar to mine when some of the Cura files were corrupted. I downloaded the latest version of Cura yesterday and noticed that the error reporting has been significantly enhanced. It also now has an option to reset the configuration files when a crash occurs. Having said that, the first time I ran the newly installed Cura it immediately crashed! I would recommend that you download the latest version of Cura 3.2.1. Before installing, uninstall the current Cura 3.2.n and delete the directories User_name/appdata/local/Cura/3.2 and User_name/appdata/roaming/Cura/3.2. Don't allow Cura to run when finishing installation (untick option). Run depends on Cura to see if the log gives any different clues.
  2. Sorry for not replying earlier, I got so frustrated with Cura that I had a play with IceSL! Returned to Cura today and managed to find what my problems were. When Cura crashes it leaves corrupted (incomplete) files in its' cache directory. On the next run Cura crashes while trying to parse these incomplete files due to 'uncaught exception' deficiencies in the Cura exe. The files are in your user_name/AppData/Roaming/Cura/3.2 - delete the directory with all contents to fix (need to select show hidden files). depends shows far more information if 'Log DllMain calls for all other messages, including thread attach and detach' is selected. You see that there are over 50 threads created and how the application attaches to resident dlls and loads other dlls as the process are created. You are able to see which thread is causing the crash and that some repeated messages are from different threads. Crashes in NTDLL are due to 'Invalid address specified to RtlFreeHeap'. These appear to be due to a 32 dll being loaded and the OS trying to generate a 'thunk' - a piece of dynamic glue code on the system heap. For some reason this seems to fail. In my case the problem occurred when a system facility which tries to cache display icons was invoked from MSI.DLL. This code is Dell specific and part of 'Dell backup and recovery'. My failure was on Windows 8.1 - the same code did not fail on Windows 10. I have temporarily removed 'Dell backup and recovery' from my laptop and Cura no longer crashes, although there are still 'First chance exception's occurring labelled as Microsoft C++ Exception. These also occur when running on Windows 10. Originally I thought that my crashes were caused by "TableViewSelection: index out of range" as appears in your 'depends' log, however I now see that when no crash occurs there is one instance of a pair of these messages. In your case there are two instances. Maybe you will be able to identify were you problem lies by running depends with /pn:1 added, this will display thread ids that will probably give you more clues.
  3. I have a laptop on which I can select whether an application uses the Processor HD4400 graphics or a NVidia GT750M. With the HD4400 Cura crashes with the same error as you have posted. Using the GT750M Cura crashes while trying to parse the printer definition file prior to initialising the graphics. In my opinion there is nothing that you can do to resolve the issue. Cura requires a manifest so that the OS can ensure the relevant environment for it to run. That can only be provided by the developer.
  4. These crashes are NOT due to missing ddls - they are caused by an inconsistent compliment of dlls. When an application does not specify its dll dependencies, the dll loader checks whether calls issued by it can be satisfied by an already memory resident dll (to save memory by not having to load a new copy of a dll). If the already loaded dll is not the same version as that used during linking this application the result is unpredictable. This was a major problem with the early versions of windows. So when an application hasn't specified its dll dependencies it is pot luck whether it will crash or not on another computer and hence cannot be considered as truly portable. Even if it does run, it should not be assumed that it will produce the same results as running on the computer where it was linked. This is true for applications on many OS's and consequently a method has been devised to solve this problem - it is called a manifest. When linking an application, generation of a manifest may be selected. On Windows the manifest may exist as a separate file in the same directory as the executable (app_name.exe.manifest) or may be incorporated into the executable. The ddl loader then uses the info in the manifest to ensure that exactly the same version of a dll is loaded or an error is issued. The application is then running the exact same code as on the original host. For example in Windows, earlier versions of ddls are under the \Windows\winsxs directory to provide backward compatibility. The manifest is missing for the Cura application, so which dlls are loaded on a particular PC depend on the current OS version, what applications are running using a manifest (resulting in a memory resident dll with the specific version for that app), order of running etc etc ... ie unpredictable!!!!. Some combinations run (how correctly cannot be specified), others crash.
×
×
  • Create New...