Using the API when Debug Session is configured to "Using Breakpoints in C/C++/.NET Applications" causes access violation

[TestStandTrent]

• Description of issue

  When using a simulated DCPower device in Max and not passing 'simulate' as an option when creating the session, the attached example generates an access violation.

• python -c "import niscope; niscope.print_diagnostic_information()" output (replace niscope with appropriate package name)

  OS:
    Name:      Windows
    Version:   10.0.17134
    Bits:      64
Driver:
    Name:      NI-DCPower
    Version:   18.1.0.49152
Module:
    Name:      nidcpower
    Version:   1.0.0
Python:
    Version:   3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64 bit (AMD64)]
    Bits:      64
    Is_Venv:   False
    Installed Packages:
        wheel==0.31.1
        six==1.11.0
        setuptools==39.0.1
        pip==10.0.1
        nidcpower==1.0.0

• Steps to reproduce issue

  1. Create a simulated 4140 in MAX
  2. run the script below and reference the simulated 4140 as you would a real one
  3. the script waits for a while and then errors, leaving the simulated device in an unrecoverable state.

import nidcpower
with nidcpower.Session(resource_name='PXI1Slot6', channels='0') as session:
    session.measure_record_length = 20
    session.measure_record_length_is_finite = True
    session.measure_when = nidcpower.MeasureWhen.AUTOMATICALLY_AFTER_SOURCE_COMPLETE
    session.voltage_level = 5.0

    session.commit()
    print('Effective measurement rate: {0} S/s'.format(session.measure_record_delta_time / 1))

    samples_acquired = 0
    print('  #    Voltage    Current    In Compliance')
    row_format = '{0:3d}:   {1:8.6f}   {2:8.6f}   {3}'
    with session.initiate():
        while samples_acquired < 20:
            measurements = session.fetch_multiple(count=session.fetch_backlog)
            samples_acquired += len(measurements)
            for i in range(len(measurements)):
                print(row_format.format(i, measurements[i].voltage, measurements[i].current, measurements[i].in_compliance))

[Fladolcetta]

This works for me on Python 64bit version 3.6.2 using NI-DCPower 18.1 (driver) and nidcpower (python) 1.0.0.

OS:
    Name:      Windows
    Version:   6.1.7601
    Bits:      64
Driver:
    Name:      NI-DCPower
    Version:   18.1.0.49152
Module:
    Name:      nidcpower
    Version:   1.0.0
Python:
    Version:   3.6.2 (v3.6.2:5fd33b5, Jul  8 2017, 04:57:36) [MSC v.1900 64 bit (AMD64)]
    Bits:      64
    Is_Venv:   False
    Installed Packages:
        virtualenv==15.1.0
        tox==2.8.2
        six==1.11.0
        setuptools==36.5.0
        pytest==3.2.2
        pytest-fixture-tools==1.0.0
        pytest-fixture-config==1.2.11
        py==1.4.34
        pluggy==0.5.2
        pip==9.0.1
        niswitch==1.0.0
        nidmm==1.0.0
        nidcpower==1.0.0

Perhaps this is a 3.6.5 issue?

[marcoskirsch]

@Fladolcetta can you try upgrading Python?

[Fladolcetta]

@Fladolcetta can you try upgrading Python?

I did upgrade to 3.7, but now I run into #895

[Fladolcetta]

I tested this with the following and it works as expected:

• Python 3.6.6 64-bit
• nidcpower 1.0.0

@TestStandTrent have you been able to reproduce this issue?

[TestStandTrent]

Yeah, i can reproduce it and it seems tied to remote debug. I have a VM that reproduces this but it has about a million things installed on it, so it's ~180GB. If you have an HDD laying around i can throw it on there.

[TestStandTrent]

This is the output I get after the crash.

Python 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64 bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> 
=============== RESTART: C:\Users\tester\Desktop\MeasureIV.py ===============
Traceback (most recent call last):
  File "C:\Users\tester\Desktop\MeasureIV.py", line 7, in <module>
    with nidcpower.Session(resource_name='PXI1Slot6', channels='0') as session:
  File "C:\Python36\lib\site-packages\nidcpower\session.py", line 3679, in __init__
    self._vi = self._initialize_with_channels(resource_name, channels, reset, options)
  File "C:\Python36\lib\site-packages\nidcpower\session.py", line 4255, in _initialize_with_channels
    errors.handle_error(self, error_code, ignore_warnings=False, is_error_handling=False)
  File "C:\Python36\lib\site-packages\nidcpower\errors.py", line 92, in handle_error
    description = session._get_error_description(code)
  File "C:\Python36\lib\site-packages\nidcpower\session.py", line 2221, in _get_error_description
    _, error_string = self._get_error()
  File "C:\Python36\lib\site-packages\nidcpower\session.py", line 2842, in _get_error
    error_code = self._library.niDCPower_GetError(vi_ctype, None if code_ctype is None else (ctypes.pointer(code_ctype)), buffer_size_ctype, description_ctype)
  File "C:\Python36\lib\site-packages\nidcpower\_library.py", line 195, in niDCPower_GetError
    return self.niDCPower_GetError_cfunc(vi, code, buffer_size, description)
OSError: exception: access violation reading 0x0000000000000000
>>> 

[texasaggie97-zz]

We have tracked this down and it is an issue with how "Using Breakpoints in C/C++/.NET Applications" is implemented. This is a feature of our drivers that allows InstrumentStudio to debug a session in use by an application.

Our Python bindings call <driver>_LockSession() and then <driver>_UnlockSession() before and after almost every method on Session(). We do this because many of the methods will need to make multiple calls into the driver so we need to lock the session to ensure that in a multi-threaded application, no other thread modifies the state of the session in the middle of the method call.

When "Using Breakpoints in C/C++/.NET Applications" is enabled, a separate server process is started that hosts the "real" session that talks to hardware, and all driver functions made by client code are remoted to that process. Because it is a separate process, the thread affinity of LockSession() doesn't work.

Internal NI bug report 717410 has been created to track this, as it is possible to fix in the server process. For now, I am marking this as wontfix but am not going to close it until CAR 717410 has been fixed, in case there is something we need to do in the Python bindings.

For now, do not enable "Using Breakpoints in C/C++/.NET Applications" when also using Python. It will also make your code faster.

[marcoskirsch]

Here's how you configure these settings, on a per-device basis:

Hint: if you don't plan to use this Debug Session functionality at all, turn it off and you'll save a bit of memory and time.

[marcoskirsch]

Now that we understand the root cause for this issue, the current title "Simulated DCPower Device in Max causes access violation" is not helpful. I am going to rephrase. I also think we should close since it's a driver issue.

[MrDuff8]

This is tracked by NI internal bug report (CAR 717410 / Bug 260694). Workaround is listed here. No longer keeping this issue open to track separately.

[rabetts]

I'm using nimi and nidcpower specifically in production test on my STS, running TestSTand 2017. This issue cost me a few days of time, since my nidcpower calls in python were working on my development STS, but not on my production machine.
Issue was I'd get a 'Connection timeout has expired' error when calling nidcpower.Session() on a real instrument, while it would work fine with {'simulate' : True}.

@marcoskirsch pointed me to this issue, and disabling the C/C++/.NET breakpoints fixed my python issue. And, debugging witinin MS visual studio still works, but I assume instrument studio can't poll the SMUs now during a breakpoint (or perhaps ever, I did not confirm).

quick screen shot showing software, plus the error thrown during an ipynb session

Realize it's a closed issue, just wanted to post here. I'd suggest this issue be brought up into your nimi docuementation/getting started guides.