Access violations while using IUIA from UIAutomationClient.dll (Win8.1 x64, Py3.4 x64)

[vasily-v-ryabov]

We use UIAutomationClient.dll through comtypes in pywinauto GUI automation project. Everything worked fine until we started using PropertyCondition objects and other more complicated things.

I found out that comtypes raises strange access violation errors on Win8.1 and even Win7.

On Win7 x64 I could get rid of them by upgrading comtypes from 1.1.1 to 1.1.2.

But on Win8.1 x64 I'm still having such errors on comtypes 1.1.2 and ActivePython 3.4.1 (64-bit).

To reproduce it just download UIA branch of pywinauto and run python.exe .\pywinauto\unittests\test_UIAWrapper.py on them. If many WPF app windows are not closed, just run taskkill /F /T /IM WpfApplication1.exe to clean them up.

The output of test_UIAWrapper.py contains the following errors:

Exception ignored in: <bound method tagVARIANT.__del__ of VARIANT(vt=0x3, 6776)>
Traceback (most recent call last):
  File "C:\Python34_x64\lib\site-packages\comtypes-1.1.2-py3.4.egg\comtypes\automation.py", line 193, in __del__
    _VariantClear(self)
OSError: exception: stack overflow
Exception ignored in: <bound method tagVARIANT.__del__ of VARIANT(vt=0x0, None)>
Traceback (most recent call last):
  File "C:\Python34_x64\lib\site-packages\comtypes-1.1.2-py3.4.egg\comtypes\automation.py", line 193, in __del__
    _VariantClear(self)
OSError: exception: access violation writing 0x0000000000420000

After that you may find pywinauto unit tests errors:

  File ".\pywinauto\uia_defines.py", line 82, in build_condition
    self.UIA_dll.UIA_ProcessIdPropertyId, process))
ctypes.ArgumentError: argument 2: <class 'OSError'>: exception: access violation writing 0x0000000000420000

Just in case:

C:\Python34_x64\Scripts\pip.exe freeze
Pillow==2.7.0
comtypes==1.1.2
coverage==4.0a5
pypiwin32==219
pypm==1.4.3
pythonselect==1.3
pywin32==219
virtualenv==1.11.6

[vasily-v-ryabov]

I got the same error on comtypes-1.1.2 after re-generating comtypes cache and re-running my client code on clean folder (Win7 x64). So it looks like not OS specific thing.

I see the comment where exception occurs:

class tagVARIANT(Structure):
    def __del__(self):
        if self._b_needsfree_:
            # XXX This does not work.  _b_needsfree_ is never
            # set because the buffer is internal to the object.
            _VariantClear(self)

It looks like this branch of code is executing somehow. But it may be a consequence of some memory corruption because of unpredictable __del__ calling moment by Python garbage collector.

[vasily-v-ryabov]

Commenting the __del__ code doesn't help. Going deeper into the issue...

After the access violation happens first time, then I'm trying to run very simple code and it's failing:

>>> comtypes.client.GetModule('UIAutomationCore.dll')
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File "C:\Python26_x64\lib\site-packages\comtypes-1.1.2-py2.6.egg\comtypes\client\_generate.py", line 97, in GetModule
    tlib = comtypes.typeinfo.LoadTypeLibEx(tlib)
  File "C:\Python26_x64\lib\site-packages\comtypes-1.1.2-py2.6.egg\comtypes\typeinfo.py", line 485, in LoadTypeLibEx
    _oleaut32.LoadTypeLibEx(c_wchar_p(szFile), regkind, byref(ptl))
WindowsError: exception: access violation writing 0x0000000000030000

So the comtypes state looks inconsistent/corrupted at all after the issue happened.

[cfarrow]

It looks like this branch of code is executing somehow. But it may be a consequence of some memory corruption because of unpredictable del calling moment by Python garbage collector.

__del__ will only be unpredictable if a comtypes object is in a reference cycle. Even then, I would not expect that to cause problems unless the object was being finalized on a thread other than the one on which it was created. (The garbage collector can run on any thread the interpreter can run on at any time the interpreter is running on that thread.) A quick search of pywinauto indicates that the project is not using multiple threads, so __del__ is probably not the culprit.

And, you have already discovered this by other means. :)

[sawantvs]

Anyone find the solution. I seen the issue on Window 10 RS1 and Windows 10 RS2

[vasily-v-ryabov]

As I mentioned in pywinauto/pywinauto#628 this issue can be stable reproduced with 64-bit Python and explorer.exe (which is 64-bit as well), but it works perfectly with 32-bit Python. The problem might be in size or alignment of some data passed by comtypes to UIAutomationCore.dll.