Today I met a boundary when creeating a routine that produces a pricelist in AX 4.0 for a webshop. When creating the required xml I was receiving the error:
Error executing code: Insufficient memory to run script.
It turns out that AX4.0 per default has a 4mb buffersize. And as the resulting xml would contain about 16 mb of data I kept getting the exception. I found good help to increase the buffersize in this post from Martin Dráb.
Recently I had the quite interesting task to debug some memory issues in a windows service.
I was quite surprised how good the various tools have become and after some reading I was quite quickly able to pinpoint where the probmelm, in this case a memory leak, was to be found.
I found to articles to be very helpful:
In my case I had to upgrade to VS 2015 enterprise to being able to debug the managed memory.
In combination the two articles describe how to get started and I recommend reading especially the first one. But if You are in a hurry this list of things to do might be helpful.
- First of all we need to create the actual memory dump
- Download ProcDump from https://technet.microsoft.com/en-us/sysinternals/dd996900.aspx and save/unzip it to a folder on the machine where your application is installed.
- Open a command prompt and switch to the folder where you saved/unzipped ProcDump.exe
- Run the command “ProcDump.exe –ma NameOfYourService.exe NameOfDumpFile
- This will create a memorydump in the same folder as where ProcDump is located.
- As described in the article on msdn, it could be a good idea to create a baseline/initial dump and afterwards create another dump to see how memory consumption evolves.
- Having created the dump file, we need to switch to Visual studio – in my case VS 2015 Enterprise
- From the files menu select “open file” and browse to select your dump file. You will see something like this
- If you do not see the “Debug Managed Memory” action, then your version of VS doesn’t support this and You will need to upgrade to a “bigger” version.
- In my scenario it was quite obvious in which area the problem were to be found – please note the “Size (Bytes)” column.
- Having the information above I could go back to my code at analyze where the objects were used and ensure proper release of the memory used by these objects.
If you know what to look for, things get a hole lot easier:-)