All, I was getting an Access Violation error in Netfabb 2020.3. My fix was to go to Settings (near the GUI Help Menu), then Display, then disable Use Advanced Display Features. This fix also described here in the post below.
Continue to get Access Violation Error in Netfabb 2021.0 after attempting to apply support structures resulting in the program crashing. Disabling "Use Enhanced Display Functions" does not correct. Any additional suggestions would be much appreciated.
Access violation errors are highly situational and very difficult to track down. Whenever you encounter them, it would be of great help if you immediately tried to reproduce them, and if successful, sent the file and a description of steps in a support ticket to us. The more examples we can collect and analyse, the higher the chance to identify the cause.
I am getting this access violation error that fully stops production work in the latest 2024 version. This appeared last Thursday it happens every time I attempt to open the program and I cannot think of anything that could have caused it to start, there were not issues prior to March 7th 2024, to my knowledge no software updates occurred until after I started debugging. I have uninstalled and reinstalled all of my autodesk products with no relief, and updated my graphics drivers.
(view in My Videos)
This clears and deletes all custom machines, any custom repair and support scripts, and other customizations not coming out of Settings > Settings (which are stored in the registry). Netfabb regenerates the folder from scratch upon its next launch. The customizations can then be put back in place from the backup one by one until the offending file or folder is identified or until all files and folders are put back without further Access Violation crashes.
Any file or folder identified as causing the crash could then be taken as a hint for what needs to be manually recreated in Netfabb (like a custom menu or a build configuration for a machine workspace, for example) or at least serve as a pointer for further investigation.
A colleague of mine is currently have issues with his install of Autocad LT 2014, everytime he uses the hatch command it crashes with the error FATAL ERROR: Unhandled access violation reading 0x007c Exception at daaadce8h.
At the moment I'm stuck for Ideas on what is causing the problem, I would be grateful for any help on this issue as I've never seen this issue before and google brings up nothing regarding this error.
I'm trying to make a set of VIs for building my packed library, updating the references in my TestStand sequence for this packed library (from the unpacked one) and making an installer out of it (the sequence and lvlibp).
In order to programmatically update the references in the seq I'm editing the .seq file first (as a normal text file) to change the paths etc. and then I'm reloading the prototypes in the sequence using the VI shown below:
During the execution of this VI I encounter Access violation (0xC0000005) at EIP=0x00000000309F9CA0 which crashes my LabView. The exception happens during the execution of the TS.Module.LoadPrototype method.
Do you expect us to see this image? Try attaching the actual VI, which allows us to closely examine the code (including anything "hidden" in other Cases, see which version of LabVIEW you are using, maybe even trying to run the code and seeing where the error pops up.
Funny thing is, that when you run these subVIs separately, manually trigger them one by one everything runs smoothly. but as soon as I run the VI shown above it crashes at the first time it calls the TS.Module.LoadPrototype method.
I was thinking that maybe it is because of some handler issues, after the build. I'm triggering the builder using NI App Builder API Build.vi in the first subVI, so maybe it has got some handlers that are not released properly? This is why I inserted the App.ClearCompObjCache and App.ClearAppBuilderCache methods, but this didn't help and I have no other idea how to check if this is an handler issue or what.
Of course it didn't help. I've also experimented with making this and/or the VI responsible for updating the prototypes in the TS sequence reentrant. Also it didn't help, it still gives me the same access violation exception.
Then, I've came with an idea (actually a friend of mine came with this idea) - lets make a copy of the lvlibp and use the copy in seq. At first it seemed great, but unfortunately - nope, it seems you cannot rename a packed library, because then there are some problems with paths inside the file, and some dependencies are braking and subVIs are not called properly... Maybe it's my fault that I can't configure the build to implement a packed-library-name-agnostic structure, but still this idea was also scrapped. And for now we have no further ideas.
Okay, so I think I found the solution for my problem, but is not the perfect one I guess... I have uninstalled NI LabView 2015 Runtime that I had on my PC why? just randomly, it didn't look okay, as I use LV 2014... not the most elegant solution, I agree. Now the VIPM is not working, but this is a minor problem.
But there is another issue. How to force TestStand Engine to use a specified LV version? PROGRAMMATICALLY. I know that you can configure the adapters manually, but I need my builder doing this automatically. Is it possible?
I need some more information in order to help you. Would you be able to share the SSU logs of both of your system so we can further check this for you? Also, what is the Minecraft version that you are referring to? Does this issue also happens with other games? Additionally, upon checking, both the error you received on Linux and Windows is related to illegal memory allocation. May I please know the RAM that you used as well on both your systems?
The minecraft version is 1.19.2, and the versions of the modpack tried were between1.0 and 1.1.
The issue only happend with this specific modpack as with the same docker command I managed to host other packs with no issues.
To be clear, the only reason why I'm posting here and not on a more minecraft related forum, is because the only people (4) who claimed having this issue were running a i9-13900 or i9-14900 processor, and the solution to this was to limit the CPU frequency to 5Ghz in windows power management.
On the previous setting you mentioned, kindly please run XTU and collect the following logs. (package temp., CPU utilization, Package TDP, Core TDP). You may download Intel XTU at this link: -extreme-tuning-utility-intel-xtu.html. You may also send the HWInfo log with 500ms step.
Please feel free to forward us the results. Furthermore, we would like to manage expectations regarding third-party applications. If you encounter any issues that are not yet compatible with Windows 11 or our CPU architecture, we encourage you to reach out to the app developers directly to address the required updates.
First of all, I don't ask you to find me a solution, I found 2 solution (One today, more at the end), and the solution I used up to now was to limit in windows power usage setting the CPU speed to 5Ghz like I mentioned earlier.
I post here mostly to try to help other people that could encounter an issue like that, or even you and because the reports we gathered were all coming from the same CPU models as the title stated.
First of all, all the time my BIOS was set to default, as before "identifying" the issue was between the process and the CPU, I tried to tweak my ram, but my last try forced me to reset the bios by removing the CMOS. It was confirmed when I got in the bios today, and it said "Bios set to default after CMOS removed" or a message like that.
I did all your step, but to be able to run the XTU software I had to disable "Virtualization Based Security", I don't know what it means, and I indeed in the past used Hyper-v (or close to this) for software like docker.
Then I ran the test with both software logs enabled as asked, the logs are around 12 minute long, and I ran, again from the XTU Tool, AVX 5 minute test, few seconds after it ended AVX2 for 5 minute, and then I ran the java process that crashed before and was the reason I posted here.
When I ran the java process it didn't crashed.
It was unexpected for me, so I tried changing the option you asked me to set one by one to identify which was fixing the issue.
It was the Processor Core IccMax that was also fixing the issue, I don't really know what it means, and if it's worse than limiting the clock speed in windows, but I checked and the process was now not crashing, and running over 5Ghz (Around 5.5Ghz almost constantly according to XTU).
May this information help in any way.
Edit 2 : This test was fine for the generation of a new world, but I had to lower it even lower to load an existing world, I'll now use 335A that seemed stable even for an existing world.
Though I received a new 14900K after just one day and now system is totally stable and no more "status access violation". Nothing else changed, just switched the CPU. So I must have had a defective core or IMC on my first CPU unfortunately. Never happened to me before, as Intel is very reliable usually!
Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.
Suppose you encounter an issue when Print Conductor processes a list of items without errors and gives an "X documents printed successfully" dialog, but the actual printing doesn't happen. In that case, there must be something wrong with your printing device.
7fc3f7cf58