Qlik Community

QlikView Administration

Discussion Board for collaboration on QlikView Management.

IMPORTANT security patches for GeoAnalytics Server available to download: READ DETAILS
Showing results for 
Search instead for 
Did you mean: 

Problem: Error Document open call failed. The document might require username and password.

Hello everyone,

I have this error on the reload of a document.

What does it means?

Here is the log of the document:

9/13/2012 08:48:07.2372382InformationAllocated QlikView Engine successfully. Current usagecount=8 of 10, Ticket=584
9/13/2012 08:48:07.2528385InformationLoading document "D:\03 Carrefour\QlikView\03 Produccion\Presentacion\Carrefour.qvw" (5900.29 Mb)
9/13/2012 08:48:08.2512577InformationLoading. LoadTime=00:00:01.0140195
9/13/2012 08:48:10.2792967InformationLoading. LoadTime=00:00:03.0420585
9/13/2012 08:48:14.3353747InformationLoading. LoadTime=00:00:07.0981365
9/13/2012 08:48:22.4475307InformationLoading. LoadTime=00:00:15.2102925
9/13/2012 08:48:38.6718427InformationLoading. LoadTime=00:00:31.4346045
9/13/2012 08:49:11.1204667InformationLoading. LoadTime=00:01:03.8832285
9/13/2012 08:50:11.9616367InformationLoading. LoadTime=00:02:04.7243985
9/13/2012 08:51:12.8028067InformationLoading. LoadTime=00:03:05.5655685
9/13/2012 08:52:13.6439767InformationLoading. LoadTime=00:04:06.4067385
9/13/2012 08:52:36.8104222ErrorDocument open call failed. The document might require username and password.
9/13/2012 08:52:36.8104222InformationAttempted to load the document with data.
9/13/2012 08:52:36.8104222ErrorThe document failed to open.
9/13/2012 08:52:37.4344342InformationClosed the QlikView Engine successfully. ProcessID=13244
9/13/2012 08:52:37.4344342ErrorDocument could not be opened
9/13/2012 08:52:37.4344342InformationClosed the QlikView Engine successfully. ProcessID=13244
9/13/2012 08:52:37.4344342ErrorThe task "BAZAR - BRICOLAGE" failed. Exception:

QDSMain.Exceptions.DistributionFailedException: Distribute failed with errors to follow. ---> System.NullReferenceException: Object reference not set to an instance of an object.

   at QDSMain.DistributeTask.ReleaseQvb(Document qvbDocument)

   at QDSMain.DistributeTask.Distribution(String fileName, DistributionRequest distributionRequest, TaskResult taskResult, String repeatVariableName, String currentRepeatVariableValue)

   at QDSMain.DistributeTask.Execute(TaskResult currentTaskResult)

   --- End of inner exception stack trace ---

   at QDSMain.DistributeTask.Execute(TaskResult currentTaskResult)

   at QDSMain.Task.AbstractTask.TaskExecution(ILogBucket logBucket, TaskResult taskResult)

9/13/2012 08:52:37.4344342InformationTask Execute Duration=00:05:17.3569029
9/13/2012 08:52:37.4344342InformationTaskResult.status=Finished
9/13/2012 08:52:37.4344342InformationNotifying all triggers of new state:FinishedWithErrors
9/13/2012 08:52:37.4344342InformationNotifying all triggers of new state:FinishedWithErrors - completed
9/13/2012 08:52:37.4344342InformationSaving Task Result

thanks in advance,,,

1 Solution

Accepted Solutions

We recently migrated (manually) our Publisher tasks from QV9 to QV11 SR2. In the process we found what runs in QV9 does not necessarily run in QV11. We to experienced the failure referenced in this post. We have roughly 200 tasks that run daily and when we started our testing process we found that a major portion of our tasks were failing with this error. The solution turned out to be a mix of things. We had a large leap between versions and the first thing we did was to make sure tasks were not competing for the same source data. This did make things better but still did not resolve all of the failures.

The next thing we tried was reconfiguring our Virus scanner to ignore QVD and QVW files. We found some errors that indicated the QVW could not be opened because another process was using it. We have not seen this error since we made the change. This was also recommended by QT support.

Next on the recommendation from QT support we disabled the Parallel reload setting in the Setting.INI file. This file is located in C:\Windows\System32\config\systemprofile\AppData\Roaming\QlikTech\QlikViewBatch\. We added a line EnableParallelReload=0 under the [Settings 7] tag at the bottom. There is no need to restart any services after adding this, as the QVB process reads the Settings.ini every time a QVB process is launched. If there is a open QVB you will not be able to save the change so make sure there are no QVB'S running. QV9 was single threaded when connected to a data source while V11 is multi threaded. The interesting bit of information on this setting change is that disabling it did not seem to affect performance at all. This setting change did improve our failure rate but still did not solve all of our issues.

The next recommendation was to increase the Client Heap setting on the server. As you know QT recommends that you have 1 less QV engine enabled than you have processors or a max of 9. We have 16 processors and we could only enable 9. As a last resort we increased or Client heap setting as recommended and we have had no failures in the last 10 days.

I would suggest you discuss these settings with QT support and at a minimum makes sure you have a test environment to test before moving them into production. The SR2 release notes indicated this issue was fixed but it can be a complex issues based on how you utilize the resources of your QV Server/Publisher.

I hope thisinformation helps.

Information on Heap Setting from QT support:

Increase Desktop Heap Memory. Done via a Windows Registry change. Documented for another scenario in our reference manual "QlikView Server/Publisher" section "Simultaneous Tasks".

Desktop Memory Heap Registry change:

Change the registry setting:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows

Change the GDI and User handle max count in the registry to SharedSection=1024,20480,2048

%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows

SharedSection=1024,20480,2048 Windows=On SubSystemType=Windows

ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3

ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off


Default is 1024,3072,512 in x86 or 1024,20480,768 in x64

NOTE! The machine must be restarted after the change

* Desktop Heap exhaust.  See links below for more info. With the workaround we will be able to avoid this problem.



Why are we having to do this?

We are creating the QVB engines as COM objects. There is a limitation from Microsoft when dealing with COM objects. COM is a fairly old technology and when Microsoft once set the limitations the machines were not as big as they are today (but has not bothered to increase this value).

Referring to this knowledge base article from Microsoft:


What changed that makes this required?

After talking an old timer here; number of QVB engines must be determined for each machine since we never know what else is running on the machine.

The way to do this is to create many QVW files with scripts that has a never ending loop (=when running the reload task, the qvb will never close). Start one task at the time and check logs to see when the engine fails to create. Manually shut down the QVD tasks in Task Manager. Redo the test a couple of time to verify that the fails at the same number of tasks. (You might need to increase the number of possible QVD engines). Now you know the limit for this machine. Doing the registry change will increase this number.

View solution in original post

19 Replies


Do you have section access in your document? If so, did you add the NTNAME of the user running the QlikView services to it? Does that happen to all tasks or only this one?

Hope that helps.



Hello Miguel, thanks for your answer...

The document doesn't have Section Access, and this is happening since today, and aparently with others documents too (pending to confirm), without any reason at all.

Is there any information I can provide you to solve this issue?




I'm assuming that you are running version 11 of QlikView Server. How many distribution engines do you have configured in the QMC? Go to the System tab, Setup, Distribution Services, click on the QDS@servername, Advance tab at the right, "Max number of simultaneous QlikView engines for distribution" and set it to the max of 4 for testing purposes.

Check as well how many tasks are running at the same time and the average time for both succeded and failed tasks.

Hope that helps.


Not applicable

Hi Miguel,

I get the same problem in QV10 SR4. I increased the QVB to 8 and then i find the CPU usage change to 100% and get the same error message as Julian.

However, if I just have Max number of simultaneous QlikView engines for distribution = 4, i will receive cannot allocation QlikView engine message and it longer the reload time.

Also, this error message may related to COM problem and if we increase the heap size it may cause another COM error message....It always fix 1 error and cause another error...

How can we balnace the number of QlikView engine we need? It's hard to keep changing the environment setting and QlikView setting as it is already in production..




The recommended number of distribution engines I always use as a general rule is, maximum, the number of cores. If you need to tweak Windows because you have a large number of cores, then do it, but that depends on Windows.

In my case, my computer has 4 cores, so I max run 3 distribution engines.

Hope that helps.


Not applicable

Hi Miguel,

Thanks for your suggestion.

I do have 12 cores but I just set it to 8. So, it should not be used up all the CPU time. Also, i wondering if the number of engine i set in engine should be equal to the number of qvb.exe appear in distribution server...The reason why i got this question is that...i set the number of distribution engine to 8...but i got 17 qvb.exe in the server running at the same time....



Although it's not required, I'd strongly recommend to stop all QlikView services then restart them again, and see if the server still triggers more than one QVB process, and if so, check with Support whether or not that's the expected behaviour.

Hope that helps.


Not applicable


I logged this case to support and hope it can be fixed.

Creator II
Creator II

Hi Julian/Nicktang,

did you solve this problem?  I have a similar symptom.