Folks,
I had both vmware workstation 6.0.5 and quicken 2008 living together happily.
I upgraded VMWare Workstation to 6.5 and I am seeing the following dialog box popup continuously when
"The procedure entry point XML_ParserCreate could not be located in the dynamic link library xmlparse.dll"
I see a event log entry as well. Event id is 26 and it comes from 'System',
The above dialog comesup if my quicken is running and I move my mouse over the vmware.exe's main window. As soon as I quit quicken the problem goes away. I get this dialog continuously as long as quicken is running and I try to do something with vmware.exe.
I have upgraded Quicken to 2009 and I still see the problem.
I noticed that both the products install their own version of xmlparse.dll in their respective installation directories. When both the procesess (vmware.exe and qw.exe) are running, I see that these respective dll are loaded from their respective installation directories.
So I wonder why one gets confused when the other one is running.
Has anyone see something similar? |
This is a known issue, and I think there will be a KB article about it.
Please complain to Intuit. If you search Google, you'll see that they conflict with some Adobe applications too.
When Quicken is running, it installs a global mouse hook that attempts to load xmlparse.dll for every mouse event (and in this case it tries to use ours instead of their own).
Workarounds would be to avoid running Quicken and Workstation simultaneously or to install Quicken in a VM.
Thanks for the quick update. This is very interesting.
What I don't understand is that it was working for me when I had workstation 6.0.5 and quicken 2008. When I upgraded to workstation 6.5, I saw the problem. May be something in WS 6.5 triggered some bug in quicken.
I am going do a similar post on the Quicken community as well.
Thanks
mapte wrote:
What I don't understand is that it was working for me when I had workstation 6.0.5 and quicken 2008. When
I upgraded to workstation 6.5, I saw the problem. May be something in WS 6.5 triggered some bug in quicken.
Strange. I can't explain that, but we did have reports about this issue in Workstation 6.0.x too.
I'm seeing the same problem with Quicken 2009 and VMware Workstation 6.5. I have found that you can use Quicken as long as you don't try to use the VM controls (I run the VM in a full screen on a 2nd monitor typically) such as the VM dropdown. Until a fix/workaround is posted, I will use Quicken and then exit it before trying to access the running VM.
My recommendation is to install Quicken in a VM. I've had nothing but troubles with Intuit software, and Intuit was the driving reason for me to start using virtualization (didn't want to keep a spare PC around just for Intuit software (Quicken and Turbo Tax). Intuit has demonstrated time and time again their disregard for their customer's PCs. I like the functionality (when it works) but their quality leaves a lot to be desired. using a VM makes dealing with Intuit messes so much easier to deal with
So - put Quicken inside a VM and know your host will be much better off.
Lawrence Quicken user for over 15 years (but not on my primary PC/host for over 8 years)
Thanks Lawrence. I'm taking you up on your recommendation as I type. ![]()
Here is some more info I found after doing some debugging.
I have workstation 6.5 running. I start Quicken 2009. If I don't move my mouse outside of the Quicken window, everything is good.
If I move my mouse to any application that does not have xmlparse.dll loaded in its context, I have no problem.
If I move the mouse to the workstation 6.5 window I get the error message.
When I move the mouse in this case to the workstation window, at this time some Quicken DLL are loaded in the context of the vmware.exe process
(dll include QWWIN.DLL, QWMAIN.DLL, QWUITL.DLL etc). I think the reason why these dlls are loaded is because of some interdependency
with the 'mouse hook' function that the Quicken application installed in the OS when it started. The hook function registered by Quicken app
is defined in one of these dlls. I found which dll's are load and when by monitoring vmware.exe using the 'process explorer' tool from 'sysinternals' website.
QWUTIL.DLL depends on xmlparse.dll, but a version of this dll provided by VMWAre (different than the one provided by Quicken)
is already loaded in the context of vmware.exe.
Now one of the Quicken dll's tries to find XML_ParserCreate function inside xmlparse.dll, but it is not provided by the vmware version currently loaded.
Hence we get the message.
Note that when things were working with workstation 6.0.5 and Quicken 2008, the version of xmlparse.dll provided by vmware do contain the XML_ParserCreate function,
hence I think I did not see any error message. Even though there is no error message, this is very bad/dangerous because, the quicken dll that is calling this function is
actually running the one provided by vmware and not quicken.
When I upgraded to workstation 6.5, it installed a new version of xmlparse.dll.
In this new dll, the function has been renamed from XML_ParserCrete to xmlrpc_XML_ParserCreate. Hence after upgrade I started getting the error.
If my analysis is correct, the bottom line is as follows:
If you have Quicken and some other application which has its own version of xmlparse.dll that does not contain XML_ParserCreate function,
then you will see the error message when you move your move to the other application's window.
I think Quicken either need to get rid of the 'global' mouse hook (which is recommended by Microsoft, unless absolutely necessary)
or need to rename their version of xmlparse.dll to something, say qwxmlparse.dll
or if possible, somehow make sure that their version of xmlparse.dll is loaded along with any other version of the same dll in the context of other applications.
I have filed a bug with Quicken with the above information. Hopefully they will be able to fix this soon.
mapte
Good sleuthing. That's mostly similar to what we did when we investigated this bug, and we came to the same conclusions. I also don't know how Quicken is trying to load their version of xmlparse.dll, but I also suspect they're calling LoadLibrary without an absolute path.
You're right about our version of xmlparse.dll; I was mistaken about this happening in WS 6.0.x.
I think the reason why xmlparse.dll is needed when the mouse moves to the vmware.exe is because the 'global' mouse hook function registered with Windows by qw.exe is implemented in one of the qw DLL's that I mentioned earlier. So when the mouse moves inside the vmware.exe windows, the OS tries to load the required qw dll's that implements this function so that it can invoke hook callback to let qw.exe track the mouse movement globally.
As part of this dll dependency tree, the OS needs to load QWUTIL.dll which has a implicit dependency on xmlparse.dll because it calls some of the XML_xxx function defined in xmlparse.dll. OS finds that some version of xmlparse.dll is already loaded (in this case the vmware version of xmlparse.dll). I don't think the OS knows how to load the quicken version of this dll, so it tries to resolve the the XML_ParserCreate function dependency in the currently loaded vmware version of xmlparse.dll and does not find it.
As I mentioned earlier, I think the easiest way to solve this is for quicken to rename their dll to say qwxmlparse.dll so that OS will not find it in any process and load the quicken version correctly.
mapte
Just a heads up, I have drafted up a KB article to spread the word to other Support Engineers here at VMware.
March 22, 2009. Problem still exists: Quicken Home and Business 2008 R9(10/27/2008), VMware 6.5.1.5078 (10/29/2008)
May 21, 2009. Problem still exists: Quicken Home and Business 2009 R2 and VMware 6.5.2 build 15675 - thanks for the insite this will definitely reduce the aggravation.
This most likely isn't a VMware problem/issue. Intuit needs to clean up their code (that is ALWAYS true) and I suspect this is as much an OS issue. Hence in Vista (and Windows 7), application can have their own copies of DLLs, to avoid these conflicts. But as I wrote earlier - running Quicken on any host is not recommended. Intuit has no respect for your PC, so put it in its own VM and save yourself a LOT of hassle. Certain applicaiton where you need every bit of your computers performance - maybe that won't work well in a VM. Or something with specific hardware requirements.
Everything else - put inside a VM. No more rebuilding/re-installing when you change/upgrade PCs, etc. My primary email/web browsing VM has been around for 5+ years now. I'm just starting to look into app virtualization (for work). Once I have that all set, maybe I won't have so many VMs
Intuit fixed the problem with Quicken 2009 R 6