Actinic Crashes since upgrading to Windows 7 64-bit

[Golf Tee Warehouse]

I am using Actinic Business V9.0.5 and two weeks moved from my old PC running Windows XP to a new PC running Windows 7 Professional 64-Bit and since the move am experiencing 3-4 crashes a day along with a dmp file each time and rarely had any problems on Win XP.

There is no one thing I am doing in Actinic that causes the crash, sometimes I might have just downloaded some orders, or sent emails or it might be when I have change tabs or clicked on a different product.

I have compacted the databases, and run a Compact and Repair through MS Access without improvement, are there any settings in Windows 7 I could try changing before I delete Actinic and reinstall.

[Gottasellbears]

I have had the same problem using windows 7 professional 32-Bit. Seems to be randomly crashing with no particular reason. Since updating to actinic business plus v10 I am yet to have the same problem. Sorry I can't help but I know your fustration.

[leehack]

I think it's pretty clear we have Windows 7 (both 32-bit and 64-bit) problems with Actinic. I wrongly assumed it was V10 related, it seems to be all versions. It's the intermittent nature of it that is frustrating as it's impossible to nail what causes each error.

If we can get someone from Actinic to be looking specifically at DMPs caused on Windows 7 systems, perhaps they can provide us with an email address to easily send them to, or maybe we can even just add them as attachments into a thread.

What can we do in this area Actinic? I think we need a specific Windows 7 thread to collate issues (perhaps a sticky?), if we add DMPs to threads, can you get someone regularly looking at these and more importantly feeding back to us what is causing the issue?

[Steve G Griggs]

Win7 and Actinic crashes

I agree there is a windows 7 problem, but for me it's only been with V9, V10.03 seems very stable on win7, in fact a previous problem I had with moving or cutting and pasting products/sections causing a crash has vanished.
The win7 + V9 combo caused frequent crashes when publishing/refreshing a site and when "snapshotting" a site.
Win Vista and V9 also seems to have a crash problem when switching from the MOTO form to the orders tab.

[Duncan Rounding]

Interestingly I've not had any crashes on W7 Pro 32bit and run v7, 8, 9 and 10 without problems.

Perhaps the issues experienced are particular to drivers or hardware.

[gcamley]

A number of problems have been raised in connection with W7 and Actinic. I would like to clarify just what the problems are.

The following is probably well known by some of the readers of this thread but it needs to be stated for those that are not aware of how the Operating System uses the RAM as only by understanding this can it be seen why upgrading to Win 7 may cause problems.

32 bit operating systems

First we need to ignore x64 Operating Systems and look at how processes work on an x86 (Win32) Operating System.

A process can be allocated a maximum of 4GB regardless of how much memory is installed on your PC. Of the 4GB, the Operating System reserves 2GB for itself and 2GB for the application (But note that a standard Win32 application cannot use/address more than 2GB of memory).

Extensive testing by Actinic about 1 year ago showed that in fact less than 2GB is actually usable by the process and processes tended to fail when they reached approximately 1.6GB. The symptoms of the failures were random crashes. In general, the more data that you have in actinic, particularly in the content tree, the more likely you are to experience the problem.

Actinic has addressed this problem in two ways in v10.0.3. The memory demands of Actinic have been significantly reduced. Sites which were requiring around 2GB RAM in 10.0.2 are requiring about 1.4GB RAM in 10.0.3 thus bringing them below the threshold.

The second change was to enable Actinic to address more than 2GB memory. As of 10.0.3 Actinic can address 3GB memory which is the limit for a Win32 application. Now things get a bit trickier. It is possible to change the behaviour of the Operating System so that on a Win32 operating system it reserves 1GB RAM for itself and allows the application up to 3GB RAM. To take advantage of the extra 1GB RAM per process it is necessary to have Actinic 10.0.3 and to modify the boot settings.

64 bit operating systems

Now we come to x64. Actinic is not a 64 bit application so I will limit the discussion to running a Win32 application on an x64 Operating System. X64 Operating Systems still allow a Win32 processes to use up to 4GB memory but they only reserve (by default) 1GB for the Operating System therefore an application may use up to 3GB as standard and so does not require a change to the boot settings. V10.0.3 under a 64 bit system can therefore be configured to use the necessary memory.
Win 7 versus earlier operating systems

I don’t have figures for Win 7 but it is more than likely that a Win 7 32bit Operating System uses more of the process memory space than for XP, this may reduce the threshold where problems start to occur below 1.6 GB. Win 7 64bit Operating System almost certainly will use more of the process space as it needs more memory due to the extended memory addressing.

Moving a v9 site to Win 7 may create issues if the process was already close to the threshold and due to the extra memory usage of Win 7 the application doesn’t have the space it previously had.

We have a number of large customers that were experiencing frequent random crashes on XP and Vista 32 bit Operating Systems who upgraded to 10.0.3 and in some, but not all cases, enabled the 3GB processing either in the boot settings or by switching to Win 7 x64 and their random crashes stopped. Those that are on Win 7 are not experiencing problems different to those experienced by others using earlier operating systems.

How do I know how much RAM my process is using?

Task Manager or Resource Monitor can be used to monitor the memory usage. Check during an upload, snapshot or hierarchical export as these tend to be the most memory intensive activities. If the process catalog.exe does not use more than 1.5GB RAM maximum then you should be okay. If the process goes beyond 1.5GB then you are reaching the point at which the memory limits may cause the application to fail. It should of course be noted that if you have less than 4GB RAM on the PC then you may have memory problems at lower values. Performance may degrade if the application has to use the pagefile.

I am approaching the upper limit on an x86 PC (Win32 Operating System), what should I do?

Increase the available RAM to at least 4GB.

Upgrading to 10.0.3 may bring the memory demands below 1.5GB thus allowing the process to work without memory restriction related crashes.

If already on 10.0.3 or upgrading to 10.0.3 has not brought the memory usage down low enough then you need to use an Operating System that allows 3GB for the application. If money is not a limitation then I would recommend moving to an x64 box with a Win 64 Operating System) and at least 4GB RAM.

If you don’t want the expense of a hardware upgrade then the only option is to enable 3GB processing on the x32 Operating System. This unfortunately comes with its own risks. The 3GB allowance is enabled for ALL processes and requires that ALL installed drivers can work with the additional 1GB. If any driver does not support the additional 1GB the system may become unstable or crash. You are advised to seek expert help when enabling the 3GB option.

If anybody feels that they are not hitting the memory threshold with 10.0.3 on Win 7 but continue to get frequent random crashes then contact Actinic Support quoting this thread and the matter will be passed to me. I will require a snapshot (if possible) or a copy of the site folder (zipped). I shall also require the dumps which can be found in the installation folder.

Useful links

Memory Limits for Windows Releases
http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx

How to enable 3GB switch support on a PC to get the full benefit of v10.0.3
http://community.actinic.com/showthread.php?p=313085

Actinic are continuing to work on this issue and we hope to reduce memory usage further in future versions of the software.

[leehack]

Thanks for the info Gordon, very useful to get some clarification. Can you shed any light on why an identical process can sometimes cause a crash, when on other times it does not. For instance do a snapshot, crashes with a DMP, open backup, repeat the process and it works fine. These are the things we struggle with. A set process on a set system seems to have varying results and works a few seconds/minutes later. Would this indicate a process sailing very close to the wind, but even if it is, why is it under the wind on one attempt and right in it on another?

Will actinic become a 64-bit application? if not, why not and could you possibly explain in laymans terms so we understand. I'm not too sure about most people, but 32-bit 64-bit is all a bit out there for me.

[Mike Hughes]

Can you shed any light on why an identical process can sometimes cause a crash, when on other times it does not. For instance do a snapshot, crashes with a DMP, open backup, repeat the process and it works fine.

No expert here, but it seems very likely to me that if you've been using actinic to make edits, add products, preview pages etc that it will already have grabbed a large chunk of memory to do this. If asked to do a snapshot at the end of this, Actinic will need a whole lot of additional memory to do this and this is probably what pushes it over the edge.

Starting Actinic again in a fresh state and doing the snapshot means it just needs the memory for the snapshot and not all the memory assigned to the previous stuff.

This does sound consistent with what Gordon has been describing.

Mike

[leehack]

So a process that has finished is hanging onto memory it does not need in effect? sounds like a viable reason, but why is it not freeing up memory if that is the case, if it doesn't free up memory not being used, it is only compounding the problem. Once used and completed, memory has to be freed up immediately or this is always going to be a big problem.

[Mike Hughes]

Memory management is a continual problem for software.

Who say's it's finished and isn't needed anymore? Is there anyway to tell Actinic that you've finished editing layouts, adding products, previewing pages, etc and it should release the memory that's being used?

Mike

[leehack]

Who say's it's finished and isn't needed anymore? Is there anyway to tell Actinic that you've finished editing layouts, adding products, previewing pages, etc and it should release the memory that's being used?

The fact that you're activating a snapshot sends a clear message to actinic that you have finished doing what you are doing, and even if you haven't and just backing up along the way, actinic should still surely, before it does anything, free up all memory before starting the process. There is no use in holding onto memory when you are about to initiate a process that is memory hungry, snapshots fail on this far more than uploads IME. The beauty of a snapshot is that you send a very clear message what you want to do (as you do with uploads).

[leehack]

An easy way to prove this theory i guess is to close down before you snapshot, open back up and then snapshot, that would answer that clearly i guess? Actinic could even do that as standard when you ask for a snapshot,, close down with a database compact, open back up and snapshot.

[Mike Hughes]

I agree with the principle and logic of what you're saying. A snapshot is a pretty clear sign of a cut off point in what's been done up to then. The same thing with an upload.

Whether the compiler and memory management tools are there to say 'release all previous memory, we've got a biggie coming' before a snapshot or upload happens is something I know nothing about. TBH I'm not sure they are as it would be expected that the OS manages memory correctly and processes shouldn't crash if they reach a certain limit.

But we could discuss this all day. You know how I like investigating new stuff and working out the details of how it all comes together. At the end of the day though it sounds as if Actinic have identified a problem with processes under windows, have already implemented some changes in V10.0.3 to mitigate the problem and have looked at ways of optimising PC setups to best avoid it.

Top marks to Actinic and I suspect this an area where we're unlikely to come anywhere close to knowing as much about the problem and how to fix it as they do. It's an area where I think we should probably leave it to the experts.

Mike

[Golf Tee Warehouse]

How do I know how much RAM my process is using?

Task Manager or Resource Monitor can be used to monitor the memory usage. Check during an upload, snapshot or hierarchical export as these tend to be the most memory intensive activities. If the process catalog.exe does not use more than 1.5GB RAM maximum then you should be okay.

Am I looking at the right place as when checking the resource manager I see a four different columns against catalog.exe and typical values I get are:
Commit:104,556 KB
Working Set: 109,080 KB
Shareable: 29,984 KB
Private: 79096 KB

I am unsure which value I should be checking against and all 4 are way below 1.6 GB and still getting regular crashes when just switching from the design tab to the orders tab and the highest memory usage for Catalog.exe I could get was around 137,000 KB

Should I instead be looking at the total Physical Memory value instead of the usage of just catalog.exe as this value is around 1450 MB, I have 4 GB installed.

[Duncan Rounding]

I believe the 1.6Gb is the total application memory of all running services, drivers and applications etc. but excluding all the windows OS components.