Stephen Smith's Blog

Musings on Machine Learning…

The Sage 300 System Manager Core DLLs

with 9 comments


We hold a developer’s exchange (DevEx) every couple of weeks where one of our developers volunteers to present to all the other developers in our office. This past week I presented at the DevEx on what all the core DLLs in our Sage 300 runtime folder do. I thought this might be of interest for a wider audience so here are the gory details.


Our marketing supplied architecture diagram is the following which highlights our three tiers and hide a lot of the details of how the object repository, APIs and supporting services are implemented. I’ve blogged previously on our Business Logic Views. In this article I’m going to go into more detail on all the DLLs that provide the framework to support all of this.


Lower Level DLLs

If you are an ISV developing Sage 300 SDK applications or have worked for Sage on the 300 product then you will have had to encounter a number of these DLLs. I’m only looking at a subset of current DLLs, and I’m not looking at all the DLLs that support older technologies that are still present to maintain compatibility with add-ons.


I didn’t add arrows to this diagram since everything pretty well calls everything else below it. But segregated the DLLs a bit by how low or high level they are. So here is a quick synopsis of each one:

A4wcompat.dll: We created this DLL back when we did a native port of the Sage 300 Views for Linux. This DLL isolates operating system differences that need more than some clever #defines. A big part of this is the thread and process synchronization and locking support. Even though we never released the native Linux version, this isolation of operating system dependent parts had made adding multi-threading support, 64 bit support and Unicode support easier.

A4wmem32.dll: In 16 bit Windows, the built in memory management was really slow, so everyone used their own. Now this DLL uses the Windows and C default memory management, but is still important for global memory that needs to be shared across processes. Originally this was done through the data segment of a fixed DLL, but now is done through memory mapped files.

A4wlleng.dll: This is just a language DLL that holds some lower level error messages used by System manager.

A4wsqls.dll: This is the SQL Server database driver (there is also a4worcl.dll for Oracle and a4wbtrv.dll for Pervasive.SQL). This is dynamically loaded based on the type of database you are connecting to. For more on our database support see this article.

Cato3msk.dll, cato3dat.dll: The cato3 DLLs are the old CA common controls. We don’t use these in our UIs anymore, but cato3msk.dll provides our mask processing that is used by the Views. Similarly we don’t use this date control, but do use a routine here to format dates in error messages correctly.

A4wroto.dll: This handles the loading of the various View DLLs as well as the various UIs we’ve used in the past. It loads the roto.dat files and handles loading the right DLLs when View subclassing is going on or stub Views need to be used.

A4wsem.dll: This handles the locking of the semaphor.bin file. It allows processes to lock the company database, an application or the whole site. It also handles application specific cross workstation locking needs.

A4wrv.dll: This is the main DLL API entry point for the Views. It manages all the calling of the Views and handles other tasks like sending the calls for macro recording. For more on our View interfaces see this article.

A4wapi.dll: This is quite a hodge-podge of services for the Views like revision lists, error reporting and such. It also has support routines for the older CA-Realizer UIs. This is quite a big DLL and has most of our C level API in it.

A4wrpt.dll: This is our interface to Crystal Reports, it started as our interface to CA-RET then was converted to Crystal using their CRPE DLL interface, then converted to Crystal’s COM interface and now uses Crystal’s .Net Interface.

A4wprgt.dll: This DLL handles replicating the system database tables into the various company databases when needed.

A4wmtr.dll: This is our meter DLL for long running processes. It can either put up a meter dialog or just report back to the caller, the current status and percent complete. It also provides the API for cancelling long running processes.

Higher Level APIs

The next level are some of the DLLs that make up our Java, COM and .Net interfaces. There is a bit of complexity here due to how our previous web deployed system worked. Here we could communicate back to the server originally using DCOM and then later with .Net Remoting. The .Net Remoting layer provides both the communications layer for this web deployed mode and also acts as our .Net API. Depending on how you create your original session will configure which actual DLLs are used and which are calling conventions are used.


A4wapiShim.dll: This is the C side of our Java JNI layer. It talks to all the lower level DLLs to get its work done.

Sajava.jar: This is the Java side of our Java JNI interface. This allows Java programs to easily call Java classes to interface to our Business Logic Views. For more on this interface see this article.

A4wcomsv.dll: This is the main workhorse for the COM and .Net APIs. It does all the heavy lifting and interfacing to the core DLLs.

Accpac.Advantage.COMSVR.Interop.dll: This just performs the .Net to COM transition which is created by the MS tools.

Accpac.Advantage.Server.dll: Server side of the .Net API, handles the .Net Remoting requests if remotely called or just passes through otherwise.

Accpac.Advantage.Types.dll: Defines all the various types we use in our .Net API.

Accpac.Advantage.dll: This is the main external interface for our .Net API. For more on our .Net API see the series of articles starting with this one.

A4wcomexps.dll: Used when the VB UIs are going to talk .Net Remoting, this DLL is inside

A4wcomex.dll: The main entry point for the COM API.

Many More DLLs

There are many more DLLs in the Sage 300 runtime, but most of the others are for obsolete APIs  like the xapi, the older a4wcom COM API, the cmd API, the icmd API, etc. There are other important ones like to do with Database Setup, but these are the main ones used when you talk to the Business Logic through one of the main popular APIs.


For anyone interested this should give you a good idea of what the main DLLs in the runtime folder do. And give you an idea of how the various services in Sage 300 ERP are layered.

Written by smist08

February 8, 2014 at 5:19 pm

9 Responses

Subscribe to comments with RSS.

  1. […] Introduction We hold a developer’s exchange (DevEx) every couple of weeks where one of our developers volunteers to present to all the other developers in our office. This past week I presented at …  […]

  2. System Manager Core DLLs provides great insight into services based ERP architecture and how perpetually living the systems become after the crucial business logic is separated from faster changing user interfaces and different database options for scalability.

    Coda: I expect Microsoft Nadella / Gates team to accelerate UI controls into browsers, building from WinJS apps in Windows 8. Good you have GWT and next generation already lined up.

    boulton clive

    February 10, 2014 at 3:04 am

  3. Hi Stephen – and thank you for sharing this very helpful article. I have a .Net 4.0 Windows application that I am using the .Net libraries for Sage 300 (6.0) on and it is generally working beautifully. The application inserts new OE Orders into the Sage 300 database. However, I have encountered a problem where the application simply crashes more or less silently. The only residue of the problem is a single event log entry on the system with the following description “Faulting application UGLBridge.exe, version, faulting module a4wcomsv.dll, version, fault address 0x0004727c.”

    I have got lots of logging within my application, and it appears to be related to a very large order (> 1000 order detail lines) but the failure does not occur at any particular part in processing this order. (i.e. it seems to be stopping at different places each time.

    In my .Net application, I have attempted to trap any unhandled exceptions using the Application.ThreadException and Application.CurrentDomain.UnhandledException events, but neither of these are being caught in this instance. As a result, the window simply disappears. (The message indicates to me that the issue is occuring somewhere within ‘a4wcomsv.dll’ – the workhorse dll you mentioned above.

    I was wondering how best to go about trying to trace this issue? IS there any sort of logging I can enable in Sage 300 that you could suggest that might help?

    Thanks in advance for any insight that you might be able to provide!

    Kind regards,

    Blair Hadfield

    April 8, 2014 at 4:28 pm

    • One other possibly relevant piece of info is that when I ran ACCPAC Spy (tracing the AccpacCOMAPI DB Link), the process appears to work properly. (other than running more slowly than usual)


      Blair Hadfield

      April 8, 2014 at 6:38 pm

      • We have seen cases where .Net memory usage is quite bad, and that if you don’t give the garbage collector a chance to run then it has problems. I wonder if Accpac Spy is allowing the GC to run. You might try adding a small sleep to see if that helps.


        April 9, 2014 at 1:02 am

      • Thank you, Stephen – I’ll give that a try.

        BTW, I have done a manual review of my integration code, and found what I hope may be the underlying issue. (that being inadvertently opening a view twice, but only closing it once )

        The bigger question for me remains (in general ) how to deal with a case like this in which there is no footprint and no real record of what went wrong. (other than the “faulting application” Event.)

        I’m keeping my fingers crossed – thanks again for your help!

        Blair Hadfield

        April 9, 2014 at 1:08 am

      • The faulting application isn’t very helpful, but I would always look for a leak type problem first when this happens. Second is wrong view compositions (but then it would never work). Otherwise the three spy programs are your best bet.


        April 9, 2014 at 1:13 am

      • Yes- thanks! I thought of the compositions early on – (having been burned by that once in the past), but the leak was a little more obscure. (I’m just hoping that’s the problem!) Anyway, thanks again.

        Blair Hadfield

        April 9, 2014 at 1:22 am

  4. Hello again. Just as an update to the problem I’m experiencing, unfortunately, the changes that I made didn’t resolve the issue. I am getting a Faulting Application crash at what feels like a random point in the process quite regularly. (It’s particularly disorienting with so little information to go on.)

    I tried adding the thread.sleep() to see if that would help, and it didn’t seem to make much difference — other than the first time I ran it with a 100ms delay between detail lines, it seemed to get further in the process. However the next run failed earlier again in the process.

    I also have tried getting a dump file, and opening it with Windbg, and it revealed an exception code of 0xC000000D (Invalid parameter – or something like that) happening within a4wcomsv.dll, but not much else from what I could see.

    The one thing that I did note is that the message in the event log has a consistent “fault address” of 0x0004727c. (even though my internal logging indicates the problem occurs when called from various different points within my own code) I am wondering if there is any way to get further with that address?

    Anyway, I am trying to run the process with RVSpy active – we’ll see how that goes.

    If there are any other avenues that I should be trying, I’m all ears!

    Blair Hadfield

    April 10, 2014 at 1:43 am

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: