| Information concerning LL_USB.ini file usage for users and developers |
|
The following explains the entries within the LL_USB.ini which is placed in your windows directory
as part of the installation process. The file is used by the DLL at runtime. Please note : The file is shipped with default parameters which are the same as would be used if the file isn't present at runtime. |
|
Sample LL_USB.ini file showing default settings with explanation of optional settings with links to full documentation for each setting |
[LL_USB] DebugLvl=0 // Sets DLL debug output capability. Valid values are currently 0-6 MsgEnable=0 // Enables application messaging. If this is set to 1, the DLL creates a dialog // box and writes runtime messages there - unless this feature has been overriden // by appplication software. If set to 0 it never creates the dialog box. MsgLevel=0 // Determines how much messaging is displayed by DLL. // 0=initialization only. // 1=all messages. Only applies if MsgEnable=1 MsgType=0 // Determines type of messaging sent. // 0=minimum user type messages. Very basic type messaging to keep user informed of // initialization progress or errors // 1=developer type messaging used for troubleshooting. // Will display actual DLL function entry points and more // of the detailed information. // Only applies if MsgEnable=1 //==================================== //==================================== // The following value should be changed // to non-zerro only if you experience // "microcode buffer wraps". // (default = 0, max=20) //==================================== //==================================== ScanSystemBoostLevel=0 // Maximum = 20. Default is 0 if this entry or this file // isn't found by the DLL, or if this this entry is a non-numeric // value. If this value is greater than 20, then the default // "maximum" value of 20 will be used by the DLL. This value may // be further reduced by the DLL depending on other parameters - see // notes below for details. // This should be set to 0 unless you experience "microcode // buffer wraps" while in scanning mode. If you change this entry, a // good starting point is 4. A lower value (other than the default of // zero or one), is used only in the rare situation where the PC is // very limited on RAM memory. // If you experience a "microcode buffer wrap" error, first try setting // "StackedIrpCntOverride" (shown below) to 20 or more and see if // that fixes the problem.Read more... //==================================== //==================================== // Following values should be set // BY FACTORY ONLY // StackedIrpCntOverride (default = 0) //==================================== //==================================== StackedIrpCntOverride=0 // Maximum = 40. This is used to override the DLL handling of this // value. If it's 0 or doesn't exist in this file, or a non-numeric // value is found in the file, the DLL will use it's own calculated value. // If the value is greater than 40, the DLL will use it's default "maximmum" // value of 40. This value may be further reduced by the DLL depending on // other parameters - see notes below for details. If you change this value, // because you are getting "microcode buffer wraps", a good starting point // is 20 - anything less could make the problem worse. A lower value (other // than the default of zero, is used only in the rare situation where the PC // is very limited on RAM memory. Read more... //======================================= //======================================= // Following increments the DLL's as well // well as calling app's thread priority // ProcessPriorityBoost (default = 0) //======================================= //======================================= ProcessPriorityBoost =0 // Maximum = (depends on operating system). Default is 0 if this entry or // this file isn't found by the DLL, or if this this entry is a value // that is non-numeric. If this value is greater than maximum (shown below, // then the default "maximum" value will be used by the DLL. // This should be set to 0 unless you experience "scan buffer" or // "microcode buffer" wraps while in scanning mode. // Setting this to 1 causes the DLL to increase it's "system priority level". // Developers should be aware that since the DLL is part of the "calling // process", your applicatiion's priority level too will be increased if // you haven't already programmed it for a high priority level. This does // not increase the priority of an application that already has a high // priority level, but rather sets it to a "higher than normal" priority // level. You can see the results of this in Win2k/XP by using the system // tools that show process priority levels. Read more... // FOR WIN98/ME // Valid values are: // 0 = default is used // 1 = high (HIGH_PRIORITY_CLASS) // FOR WIN2k/XP // 0 = NORMAL_PRIORITY_CLASS; // 1 = HIGH_PRIORITY_CLASS; // 240 (0xF0) = IDLE_PRIORITY_CLASS; // 241 (0xF1) = REALTIME_PRIORITY_CLASS; //******************************************************************* //******************************************************************* //FIRST TWO ARE RECOMMENDED AND AVAILABLE IN Win98/ME/2k/XP //3rd and 4th availabe only in Win2k/XP //4th and 5th documented by microsft, but not available at this time. //******************************************************************* //******************************************************************* //NORMAL_PRIORITY_CLASS -> Process with no special scheduling needs. //HIGH_PRIORITY_CLASS-> Process that performs time-critical tasks that must be // executed immediately. The threads of the process preempt the threads of normal // or idle priority class processes. An example is the Task List, which must // respond quickly when called by the user, regardless of the load on the // operating system. Use extreme care when using the high-priority class, because // a high-priority class application can use nearly all available CPU time. //FOLLOWING MAY BE TOO SLOW FOR SCANNING MODE!!! //IDLE_PRIORITY_CLASS-> Process whose threads run only when the system is idle. // The threads of the process are preempted by the threads of any process running // in a higher priority class. An example is a screen saver. The idle-priority class // is inherited by child processes. NORMAL_PRIORITY_CLASS-> Process with no special // scheduling needs. //FOLLOWING NOT RECOMMENDED!!!! //REALTIME_PRIORITY_CLASS-> Process that has the highest possible priority. The // threads of the process preempt the threads of all other processes, including // operating system processes performing important tasks. For example, a real-time // process that executes for more than a very brief interval can cause disk caches // not to flush or cause the mouse to be unresponsive. //Following to be supported in future versions of Windows? //ABOVE_NORMAL_PRIORITY_CLASS-> Windows 2000/XP: Process that has priority above // NORMAL_PRIORITY_CLASS but below HIGH_PRIORITY_CLASS. //Following to be supported in future versions of Windows? //BELOW_NORMAL_PRIORITY_CLASS-> Windows 2000/XP: Process that has priority above // IDLE_PRIORITY_CLASS but below NORMAL_PRIORITY_CLASS. |
| [LL_USB] main entry |
|
DebugLvl |
|
Default: DebugLvl=0 Example: DebugLvl=2 This entry can be used for troubleshooting issues associated with functionality of DLL and it's interraction with the running application and the device driver. By default this value is set to 0. When the value is non-zero, the DLL will create a folder called M30x_DBG. It will then create a file with a name that is made up of the running application's main window handle and the number of times that the DLL's initialization process has been called. For example, "7B0130_0.txt could be a debug filename. The DLL will then write vaious runtime information to the file. The minumum debug output is 1 and the maximum is 5. It is not recommended that any value greater than 3 be used except under extreme troubleshooting conditions since a very large debug file can be created very quickly especially when the device is in scanning mode. A great deal of information can be obtained by simply setting the value to 2 or 3 and is the setting we usually use at the factory when testing the robustness of the DLL, device driver, and related calling applications. Click here to see an example of a debug file that was created by us at the factory. At the left margin of the file, you'll notice a number, which is then followed by a space and then sometimes another number such as, "6699460 2742:". The first number is the "clock" shown as number of milliseconds that have elapsed since the DLL was loaded, followed by the "Device ID" represented by a hexedecimal value. The value shown above for the "clock" shows that the line was added to the file 6 minutes, 699 seconds, and 460 milliseconds after the DLL was loaded. The "Device ID" is shown in hexidecimal format. To convert it to decimal format which is the number shown on the actual hardware chip, the Windows calculator can be used. |
|
MsgEnable |
|
Default: MsgEnable=0 Example: MsgEnable=1 We no longer recommend setting this entry or the two that follow to anything except zero, but a setting of one is still supported for backward compatibility. When an application makes a call to the DLL's DisableDialog() function, these three entries are ignored by the DLL since they are related only to the type of messages that will be displayed to a Windows Message Box (if any). If this entry is set equal to "0", the resources used by the message box will still be used, but the message box will never be displayed. If this entry is set to 1, the message box will be displayed whenever there are messages available to show to the user but the amount of messages will be controlled by the next two entries that follow. |
|
MsgLevel |
|
Default: MsgLevel=0 Example: MsgLevel=1 This entry and the one that follows are ignored if the previous entry is set equal to zero. Otherwise this entry works with the one that follows to control the amount of messages that are displayed when messaging to the Windows Message Boxes is enabled. This entry, although not currently being used at the time of this documentation, has been and may again be used in the future to control the amount of messaging that will be sent - similar to the functionality of the DebugLvl entry in regard to debug file output. |
|
MsgType |
|
Default: MsgType=0 Example: MsgType=1 This entry and the previous one are ignored if the MsgEnable entry is set equal to zero. Otherwise this entry will determine if intense trouble-shooting type messages are displayed or just basic, somewhat informative type messages are displayed. We recommend that this entry be left set to zero except when troubleshooting. It is more effective to use the debug file output options described further up in this documentation for troubleshooting purposes. |
|
ScanSystemBoostLevel |
|
Default: ScanSystemBoostLevel=0 Example: ScanSystemBoostLevel=10 This entry and the one that follows controls functionality of the device driver and it's interraction with lower-level drivers that are part of the operating system kernel. This entry is only used during scanning mode. We recommend that you only set this entry to a non-zero value when there is an indication of the data buffer within our device experiencing an "overflow" which results in wrapping of it's circular buffer. Such a wrap is the result of our device driver not receiving anough of a time-slice from the kernel in order to keep the device's buffer empty. We recommend that if a "microcode buffer wrap" situation occurs, that you first set the StackedIrpCntOverride (discussed next) to a non-zero value and continue to increase it to it's maximum setting of 40 to try to cure the problem, before changing this value to a non-zero (or 1) value. Setting this entry to either 0 or 1 has the same effect. The driver will occassionally lower the boost value based on various conditions that would make the boost impractical and as a result also disrupt the error handling built into the driver. Since an increase in boost translates to a larger packet of data being returned by the low-level driver with each read request, a very high boost factor combined with a very slow scan rate could create a condition in which the low-level driver takes many seconds or even minutes to return with one packet of data. Since our device driver has built in request-return timeouts built in as part of it's error handling, a large boost factor will be adjusted in such a way as to create a maximum time per packet request to be 1.5 seconds or less. Likewise if the boost exceeds the maximmum boost, it will be adjusted to the maximum before further adjustments are made as described above. The low-level kernel drivers have the highest time-slicing priority. Using this entry takes advantage of that issue. Setting this entry to a non-zero value has the effect of our driver requesting a larger amount of data be read with each read done by the low-level drivers. The side effect is that more time is required per-read by the DLL and thus the application. For example, when in scanning mode and with this value set to zero (or 1) our USB device will return a minumum of 32 bytes with each read - 30 of which are data (1 point = 3 bytes) - which translates into 10 points of data when doing a non-digital-input type of scan. Setting this entry to 2, doubles that to 20 points nd setting it to 3 triples it to 30 points per read. The rate at which the device scans for data is in no way effected by this setting - only the rate at which the data is returned to the user. To further explain... if you set up to scan at 300Hz with this entry set to 0 or 1, you can read 10 points of data 30 times each second. Likewise, with this entry set to 10 with the same scan rate, you can read 100 points of data 3 times each second. In all the previous mentioned situations, the device reads the analog input 300 times per second and all the digital conversions are returned to the user. We added this entry when we discovered that running the "Pinball" game that ships with WinME and later releases would take time-slicing away from our device driver even though it was running a high priority. However, we also observed that the "Pinball" game didn't have an effect on the "low-level" drivers which continued to get their usual time slice. Other drivers that "hog the system" can also have an effect on the slicing allocated to our driver but none seem to effect the slicing allocated to the low-level USB drivers that ship with the operatings system. |
|
StackedIrpCntOverride |
|
Default: StackedIrpCntOverride=0 Example: StackedIrpCntOverride=20 This entry, like the previous one, controls functionality of the device driver and it's interraction with lower-level drivers that are part of the operating system kernel. This entry is only used during scanning mode. The entry name represents the "Stacked Interrupt Request Packet Count Override". We recommend that you only set this entry to a non-zero value when there is an indication of the data buffer within our device experiencing an "overflow" which results in wrapping of it's circular buffer. Such a wrap is the resulst of our device driver not receiving anough of a time-slice from the kernel in order to keeep the device's buffer empty. We recommend setting this entry to a non-zero value before changing the ScanSystemBoostLevel previously discussed. If this entry is non-zero, the DLL will make further adjustments to it based on several scan setup parameters as to create the optimum setting for this value. If left at zero, or if the entry isn't present in the .ini file, the DLL will make no adjustment to the value. The low-level kernel drivers have the highest priority as far as their time-slicing. Using this entry (like the previous one) takes advantage of that issue. Setting this entry to a non-zero value has the effect of our driver requesting more "packets of data" with each request, while the previous entry results in a request for "larger packets) with each request. The advantage that this has, is it keeps a constant stack of requests backed up for the low-level driver to read while our driver is processing and sending back to the DLL the data that has already been read. The low-level drivers return each packet to our driver as it is read before it begins to fill the request for the next packet that is waiting on it's stack. Fortunately, this process has little or no adverse effects on the higher-level processes other than it can require more memory in a quantity proportional to the number of stacked requests. |
|
ProcessPriorityBoost |
|
Default: ProcessPriorityBoost=0 Example: ProcessPriorityBoost=1 This entry is seen by the DLL as an indicator to increase it's system priority level. The effect that such an increase has is it gives the DLL and the application that is making use of the DLL a very high priority level. This, when used with appropriate settings of the other options within this file can help eliminate issues in regard to DLL and microcode data buffer wraps as described further down. Windows manages many tasks at the same time by giving a slice of time to each of the applications and processes that are running at any given time. Typically, each process is given an equal slice of the time. However, some applications have time critical issues that have to be dealt with and sometimes when a lot of applications are running, the slice that they receive just isn't enough to accomplish what needs to be accomplised within a given frame of time. Applications that use our DLL, especially when scanning for data a high rates can encounter such a defecit of time slicing. Setting this value to "1" will cause the DLL make a request to the operating system to increase it's time-slicing by a factor of 4. In other words, it will now get four times as much of a slice as it would ordinarily have. Increasing the priority level can help prevent buffer wraps in a number of ways. There are two main buffers used when using a scanning type mode. One is at the application level and resides in a special memory space that is available to both the DLL and device driver. That memory space is very similar to the virtual disk space used as extra storage for system memory activity. As the device driver reads data from the device, it writes the data into that memory and it is then up to the DLL to read the data from it in order to keep it from filling and overflowing. If many applications are running in the background, the time slice that the application/DLL have to read the data isn't enough and the buffer can overflow. This is ofter reported to the application by way of the DLL and also to the debug file (if one is utilized) also by the DLL as a "Scan Buffer Wrap". Likewise, a wrapping of the device's buffer can also occur if the device driver doesn't call it frequently enough to keep it's buffer from overflowing. Since the device driver has such a high prirority (much more than any application) the device driver is usually only affected indirectly by a background application that has a high priority level and at the same time is interracting with it's own device driver which may have a higher priority level than our own device driver. Such a situation can be less obvious since any application can indirectly make use of a kernel driver just by making a lot of memory hits that make use of a kernel driver that then uses the hard disk to cache some of that memory out to virtual memory. //******************************************************************* //******************************************************************* // Here is more information about this setting //******************************************************************* //******************************************************************* // FOR WIN98/ME // Valid values are: // 0 = default is used // 1 = high (HIGH_PRIORITY_CLASS) // FOR WIN2k/XP // 0 = NORMAL_PRIORITY_CLASS; // 1 = HIGH_PRIORITY_CLASS; // 240 (0xF0 hex) = IDLE_PRIORITY_CLASS; // 241 (0xF1 hex) = REALTIME_PRIORITY_CLASS; //******************************************************************* //******************************************************************* //FIRST TWO ARE RECOMMENDED AND AVAILABLE IN Win98/ME/2k/XP //3rd and 4th availabe only in Win2k/XP //4th and 5th documented by microsft, but not available at this time. //******************************************************************* //******************************************************************* //NORMAL_PRIORITY_CLASS -> Process with no special scheduling needs. //HIGH_PRIORITY_CLASS-> Process that performs time-critical tasks that must be // executed immediately. The threads of the process preempt the threads of normal // or idle priority class processes. An example is the Task List, which must // respond quickly when called by the user, regardless of the load on the // operating system. Use extreme care when using the high-priority class, because // a high-priority class application can use nearly all available CPU time. //FOLLOWING MAY BE TOO SLOW FOR SCANNING MODE!!! //IDLE_PRIORITY_CLASS-> Process whose threads run only when the system is idle. // The threads of the process are preempted by the threads of any process running // in a higher priority class. An example is a screen saver. The idle-priority class // is inherited by child processes. NORMAL_PRIORITY_CLASS-> Process with no special // scheduling needs. //FOLLOWING NOT RECOMMENDED!!!! //REALTIME_PRIORITY_CLASS-> Process that has the highest possible priority. The // threads of the process preempt the threads of all other processes, including // operating system processes performing important tasks. For example, a real-time // process that executes for more than a very brief interval can cause disk caches // not to flush or cause the mouse to be unresponsive. //Following to be supported in future versions of Windows? //ABOVE_NORMAL_PRIORITY_CLASS-> Windows 2000/XP: Process that has priority above // NORMAL_PRIORITY_CLASS but below HIGH_PRIORITY_CLASS. //Following to be supported in future versions of Windows? //BELOW_NORMAL_PRIORITY_CLASS-> Windows 2000/XP: Process that has priority above // IDLE_PRIORITY_CLASS but below NORMAL_PRIORITY_CLASS. |
| Sample Debug File output |
This log file created: Thu Oct 10 12:30:45 2002
This DLL compilation date/time: Oct 10 2002, 12:30:20
This DLL version: 10,8,2002,0
InitDLL(...)-> parent window HANDLE: 0x7B0130, Debug Level: 2
6681524 Entering DLL_Init()
6681584 DLL_Init(...)-> DLL Name: LL_USB2k.DLL
6681604 DLL_Init(...)-> Win Numeric Version: 0xA280105
6681624 DLL_Init(...)-> Floating point info: In rare circumstances, a floating-point precision error can occur (Pentium)
6681634 DLL_Init(...)-> Floating point info: In rare circumstances, a floating-point precision error can occur (Pentium)
6681654 DLL_Init(...)-> User Name: TIM
6681664 DLL_Init(...)-> Windows Version Info:.
dwOSVersionInfoSize: 148
dwMajorVersion: 0x5
dwMinorVersion: 0x1
dwBuildNumber: 2600
dwPlatformId: Win32 on Windows NT
szCSDVersion:
6681684 DLL_Init(...)-> System Info:
wProcessorArchitecture: PROCESSOR_ARCHITECTURE_INTEL
dwPageSize : 4096
lpMinimumApplicationAddress: 0x41EEC6C
lpMaximumApplicationAddress: 0x41EEC70
dwActiveProcessorMask: 1
dwNumberOfProcessors: 1
dwProcessorType: 586
dwAllocationGranularity: 65536
wProcessorLevel 6, (Processor name unavailable)
wProcessorRevision: 2051
6681714 DLL_Ini(...)-> Calling DLL_SetPriorityMsgHandling_CPP()
6681734 Priority messaging will be sent to Application callback..
6681744 DLL_Init(...)-> Calling InitDLL().
6681764 InitDLL(...)-> parent handle: 0x130
6681784 InitDLL(...)-> mapped file mmfSharedAppHandle already exists. This is not an error.
6681794 InitDLL(...)-> s_hFileMapAppHANDLE: 0x560
6681814 InitDLL(...)-> success creating mapping for lpListViewAppHANDLE
6681834 InitDLL(...)-> mapped file mmfSharedGUIDListData already exists. This is not an error.
6681854 InitDLL(...)-> s_hFileMapGUID: 0x554
6681874 InitDLL(...)-> success creating mapping for lpListViewGUID
6681894 InitDLL(...)-> mapped file: mmfSharedDeviceIDListData already exists. This is not an error.
6681924 Entering GetDeviceIDList(...)
6681944 CheckAndSetDevIDAccessFlag(...)-> Setting ACCESS RESTRICTION FLAG -> pLLABS_DeviceIDList_DLL_SHARED[32].
6681965 GetDeviceIDList(...)-> Probing for attached devices
6681985 Entering GetUsbDeviceCnt(...)
6682015 Entering OpenOneDevice
6682035 OpenOneDev(...)-> Attempting to open: \\?\usb#vid_0724&pid_0004#5&630c392&0&1#{36fc9e60-c465-11cf-8056-444553540000}
6682055 OpenOneDev(...)-> SUCCESS OPENING \\?\usb#vid_0724&pid_0004#5&630c392&0&1#{36fc9e60-c465-11cf-8056-444553540000}
6682085 Leaving OpenOneDev(...) SUCCESS
6682105 ### GetUsbDeviceCnt(...)-> Following WERE found
6682125 GetUsbDeviceCnt(...)-> GUID: 36fc9e60-c465-11cf-8056-4445535400
6682175 GetUsbDeviceCnt(...)-> outNameBuf: \\?\usb#vid_0724&pid_0004#5&630c392&0&1#{36fc9e60-c465-11cf-8056-444553540000}
6682195 index: 0, number of devices: 1
6682215 GetUsbDeviceCnt(...)-> Last Item Located
6682235 GetUsbDeviceCnt(...)-> Number of devices: 1
6682255 Leaving GetUsbDeviceCnt(...) SUCCESS
6682375 GetDeviceIDList(...)-> GetUsbDeviceCnt() Found the following:
6682425 &pDeviceNameList_DLL_SHARED_TEMP[0]:
\\?\usb#vid_0724&pid_0004#5&630c392&0&1#{36fc9e60-c465-11cf-8056-444553540000}
6682465 Found a matching GUID in original list at: 0
6682485 GetDeviceIDList(...) -> CompleteDeviceName:
\\?\usb#vid_0724&pid_0004#5&630c392&0&1#{36fc9e60-c465-11cf-8056-444553540000}
6682515 Entering OpenFile_WithGUID(...), GUID:
\\?\usb#vid_0724&pid_0004#5&630c392&0&1#{36fc9e60-c465-11cf-8056-444553540000}
6682535 OpenFile_WithGUID(...) -> CompleteDeviceName:
\\?\usb#vid_0724&pid_0004#5&630c392&0&1#{36fc9e60-c465-11cf-8056-444553540000}\PIPE01
6682555 OpenFile_WithGUID(...) ->
\\?\usb#vid_0724&pid_0004#5&630c392&0&1#{36fc9e60-c465-11cf-8056-444553540000}\PIPE01 Opened Successfully
6682565 Leaving OpenFile_WithGUID(...) SUCCESS
6682585 Entering OpenFile_WithGUID(...), GUID:
\\?\usb#vid_0724&pid_0004#5&630c392&0&1#{36fc9e60-c465-11cf-8056-444553540000}
6682605 OpenFile_WithGUID(...) -> CompleteDeviceName:
\\?\usb#vid_0724&pid_0004#5&630c392&0&1#{36fc9e60-c465-11cf-8056-444553540000}\PIPE00
6682646 OpenFile_WithGUID(...) ->
\\?\usb#vid_0724&pid_0004#5&630c392&0&1#{36fc9e60-c465-11cf-8056-444553540000}\PIPE00 Opened Successfully
6682666 Leaving OpenFile_WithGUID(...) SUCCESS
6682676 Calling GetDevIDAndSetArrayIndex_IOCTL Handle: 0x57C List Index: 0, and GUID:
\\?\usb#vid_0724&pid_0004#5&630c392&0&1#{36fc9e60-c465-11cf-8056-444553540000}
6682696 Entering GetDevIDAndSetArrayIndex_IOCTL(...) for DEV:
\\?\usb#vid_0724&pid_0004#5&630c392&0&1#{36fc9e60-c465-11cf-8056-444553540000}
6682716 Using handle: 0x57C, List index: 0
6682726 GetDevIDAndSetArrayIndex_IOCTL(...)-> Got ID: 0x2742
6682746 Leaving GetDevIDAndSetArrayIndex_IOCTL(...) SUCCESS
6682766 GetDeviceIDList(...) -> DevID: 0x2742 already shown in list but shown as disconnected
6682776 AFTER finding all available devices in GetDeviceIDList(). Ready to call ShowLists()
6682796 DLL's copy of devices still in app's list - DEC:
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
6682816 pLLABS_DeviceIDList_DLL_SHARED (all devices in shared memory - HEX):
2742 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Numbers in HEX. If upper bit set, Device is unplugged.
6682826 DLL's App-Handle List (all indexes currently owned by any app):
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
6682846 Ready to exit GetDeviceIDList(). Ready to call ShowLists()
6682866 DLL's copy of devices still in app's list - DEC:
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
6682876 pLLABS_DeviceIDList_DLL_SHARED (all devices in shared memory - HEX):
2742 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Numbers in HEX. If upper bit set, Device is unplugged.
6682896 DLL's App-Handle List (all indexes currently owned by any app):
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
6682916 Entering GetDriverVersion(...)
6682926 GetDriverVersion(...) -> SUCCESS in call to DeviceIoControl - IOCTL_GET_DRIVER_VERSION.
6682946 GetDriverVersion(...) ->
DRIVER VERSION STRING (from driver): 10,8,2002,0
DRIVER VERSION STRING (from DLL ): 10,8,2002,0
6682966 Exiting GetDeviceIDList(...) SUCCESS
6682976 InitDLL(...)-> back from GetDeviceIDList(...)
6682996 InitDLL(...)-> bNumDevicesInSharedList: 1
6683016 InitDLL(...)-> pLLABS_DeviceIDList_DLL_SHARED[0]: 0x2742
6683026 InitDLL(...)-> pDeviceNameList_DLL_SHARED[0]:
\\?\usb#vid_0724&pid_0004#5&630c392&0&1#{36fc9e60-c465-11cf-8056-444553540000}
6683046 Exiting InitDLL(...)-> SUCCESS
6683066 Exiting DLL_Init(...)-> SUCCESS
6683076 #### SP_InitAllDevices(...)-> pDevList : 10050, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
6683096 #### SP_InitAllDevices(...)-> pdblDevRate : 1000.000000, 0.000000, 0.000000, 0.000000, 0.000000,
0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000,
0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000,
0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000,
6683116 SP_InitAllDevices(...)-> Searching for connected devices
6683126 ENTERING InstanceInitDeviceList_LOCAL(...)
6683146 CheckAndSetDevIDAccessFlag(...)-> Setting ACCESS RESTRICTION FLAG -> pLLABS_DeviceIDList_DLL_SHARED[32].
6683156 ENTERING InstanceInitDeviceList_LOCAL().
6683176 BEFORE comparing app's list with shared list in InstanceInitDeviceList_LOCAL()
App's ID List:: 2742 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
6683196 Calling ShowLists().
6683206 DLL's copy of devices still in app's list - DEC:
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
6683226 pLLABS_DeviceIDList_DLL_SHARED (all devices in shared memory - HEX):
2742 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Numbers in HEX. If upper bit set, Device is unplugged.
6683246 DLL's App-Handle List (all indexes currently owned by any app):
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
6683256 2742: InstanceInitDeviceList_LOCAL(...)-> Found this DevID and pipes are open
6683276
READY TO EXIT InstanceInitDeviceList_LOCAL().
6683296 AFTER comparing app's list with shared list in InstanceInitDeviceList_LOCAL()
App's ID List:: 2742 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
6683306 Calling ShowLists().
6683326 DLL's copy of devices still in app's list - DEC:
10050 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
6683347 pLLABS_DeviceIDList_DLL_SHARED (all devices in shared memory - HEX):
2742 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Numbers in HEX. If upper bit set, Device is unplugged.
6683357 DLL's App-Handle List (all indexes currently owned by any app):
7B0130 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
6683577 SP_InitAllDevices(...)-> Opening device: 10050
6683587 ###SP_InitAllDevices(...)-> Rate: 1000.000000 Device: 10050
6683607 Entering SP_Signon() DEVICE: 0x2742
6683617 2742: Entering GetStructMappedMemSingleReadWrite(...)
6683637 2742: GetStructMappedMemSingleReadWrite(...)-> Success creating/opening memory mapped file:
mmfSharedDriver_2742_STRUCT_WRITE.
6683657 2742: GetStructMappedMemSingleReadWrite(...)-> Success creating view of memory mapped file:
mmfSharedDriver_2742_STRUCT_WRITE. Pointer Address: 0x3950000
6683667 2742: Exiting GetStructMappedMemSingleReadWrite(...)
6683687 Entering GetDataMappedMemSingleReadWrite(...)
6683707 GetDataMappedMemSingleReadWrite(...)-> Success creating/opening memory mapped file:
mmfSharedDriver_2742_DATA_WRITE.
6683717 GetDataMappedMemSingleReadWrite(...)-> Success creating view of memory mapped file:
mmfSharedDriver_2742_DATA_WRITE. Pointer Address: 3960000
6683737 Exiting GetDataMappedMemSingleReadWrite(...). SUCCESS
6683757 2742: Entering "DLL_RWOD(...)" FOR READ of DEVICE: 0x2742
6683767 2742: Entering GetStructMappedMemSingleReadWrite(...)
6683787 2742: GetMappedMem(...)->Success creating/opening memory mapped file: mmfSharedDriver_2742_STRUCT_READ.
6683797 2742: GetStructMappedMemSingleReadWrite(...)-> Success creating view of memory mapped file:
mmfSharedDriver_2742_STRUCT_READ. Pointer Address: 0x3970000
6683817 2742: Exiting GetStructMappedMemSingleReadWrite(...)
6683837 Entering GetDataMappedMemSingleReadWrite(...)
6683847 GetDataMappedMemSingleReadWrite(...)-> Success creating/opening memory mapped file:
mmfSharedDriver_2742_DATA_READ.
6683867 GetDataMappedMemSingleReadWrite(...)-> Success creating view of memory mapped file:
mmfSharedDriver_2742_DATA_READ. Pointer Address: 3980000
6683887 Exiting GetDataMappedMemSingleReadWrite(...). SUCCESS
6685730 2742: RWOD(...)-> SUCCESSFUL READ:
SR_ReadCompleted: 0x1
SR_CntBytesRead: 32
SR_Status: 0x8B
SR_DrvrRetStatus: 0x1
6685750 Bytes from SIGNON Successful calibration: 1 2 3 23 0 8C 0
6685770 SP_Signon() returning SUCCESS for DEVICE: 0x2742
6685780 SP_InitAllDevices(...)-> Success opening device: 10050
6685800 SP_InitAllDevices(...)-> Rate: 1000.000000 Device: 10050
6686030 Entering SP_SendRate(...). usDevID: 10050, dblRate: 1000.000
6686040 SP_SendRate(...)-> Calling SP_CalcRateCodes()
6686060 ** ENTERING SP_CalcRateCodes() for DevID: 10050, rate: 1000.000000
6686070 SP_CalcRateCodes()-> Rate has been adjusted from: 1000.0000 to: 1000.6515
6686090 SP_SendRate(...)-> SP_CalcRateCodes() SUCCEEDED!
6686110 SP_SendRate(...)-> bLow: 33, bMid: 0, bHigh: 81
6686121 SP_SendRate(...)-> Waiting settling time for SysCal for DevID: 10050
6686141 2742: Entering "DLL_RWOD(...)" FOR READ of DEVICE: 0x2742
6688013 2742: RWOD(...)-> SUCCESSFUL READ:
SR_ReadCompleted: 0x1
SR_CntBytesRead: 32
SR_Status: 0x8B
SR_DrvrRetStatus: 0x1
6688033 Bytes from 1000.651 Hz calibration: 1 2 3 23 0 81 33
6688043 bLow: 33, bMid: 0, bHigh: 81
6688063 SP_SendRate(...)-> System calibration SUCCEEDED for DevID: 10050
6688083 2742: Entering: DLL_SetRate(...)
6688093 2742: sRate: 1000.651466
6688113 Exiting: DLL_SetRate(...) SUCCESS
6688133 2742: Entering: DLL_SetRate(...)
6688143 2742: sRate: 1000.000000
6688163 Exiting: DLL_SetRate(...) SUCCESS
6688183 Entering DllEntryPoint()
6688193 Exiting DllEntryPoint point
6691929 2742: Entering: DLL_StartScan_DIO(...).
6691969 2742: Entering "DLL_RWOD(...)" FOR READ of DEVICE: 0x2742
6691989 2742: RWOD(...)-> SUCCESSFUL READ:
SR_ReadCompleted: 0x1
SR_CntBytesRead: 32
SR_Status: 0x8B
SR_DrvrRetStatus: 0x1
6691999 2742: ##### SCAN_SendStartToken(...)-> FIRST READ bytes read : 1, 2, 0, 23, C7, FF, 7F, 0, 70, 90,
1, 3, 5A, A, 0, 0, 0, 0, 0, 0, 60, 38, 24, 0, B0, 5B, 1, 3, F0, ED, 12, 0,
6692019 2742: Entering: SCAN_SetupScan_DIO(...). Device ID = 0x2742
6692029 2742: Entering: SCAN_SetupScanMemMappedFiles(...). Device ID = 0x2742
6692049 2742: SCAN_SetupScanMemMappedFiles(...)-> Success creating/opening memory mapped file:
mmfSharedDriver_2742_SCAN_STRUCT.
6692069 2742: ### SCAN_SetupScanMemMappedFiles(...)-> Setting Rate: 1000.
6692079 2742: SCAN_SetupScanMemMappedFiles(...)-> SCAN_uiDataBuffSize: 32760.
6692099 2742: SCAN_SetupScanMemMappedFiles(...)-> Success creating/opening memory mapped file:
mmfSharedDriver_2742_SCAN_DATA.
6692119 2742: Entering SCAN_InitDevDrvrScanMemPtrs(...)
6692129 2742: Exiting SCAN_InitDevDrvrScanMemPtrs(...) SUCCESS
6692149 2742: Exiting: SCAN_SetupScan_DIO(...) SUCCESS
6692169 2742: DLL_StartScan_DIO(...)-> SO_bScanType: 4, SO_Rate: 1000.000000, SO_SizeVoltageArray:
1 6384
6692179 2742: Entering SCAN_InitDevDrvrScanThread(...)
6692199 2742: SCAN_InitDevDrvrScanThread()-> bScanSystemBoost: 20
6692219 2742: SO_bScanType: 4
6692229 2742: SO_bScanArg: 8
6692249 2742: SCAN_InitDevDrvrScanThread()-> StackedIrpCntOverride (from .ini): 40
6692269 2742: SCAN_InitDevDrvrScanThread()-> StackedIrpCntOverride (from .ini): 40
6692279 2742: SCAN_InitDevDrvrScanThread()-> apScanStructArray[0]->SCAN_bStackedIrpCntRequest: 40
6692299 2742: SCAN_InitDevDrvrScanThread()-> Success creating ScanThreadDLL2DriverAccessControl()
6692319 2742: SCAN_InitDevDrvrScanThread()-> Success creating ScanThreadDLL2DriverAccessControl()
SCAN_IniEntering DllEntryPoint()
6692329 2742: SCAN_InitDevDrvrScanThread()-> Success creating SCAN thread
6692369 2742: SCAN_InitDevDrvrScanThread(...)-> Starting wait for fIOCTL_Scan_CallStarted == TRUE.
SCAN_IniExiting DllEntryPoint point
6692400 Entering DllEntryPoint()
6692420 Exiting DllEntryPoint point
6692430 2742: Entering ScanThreadFunc_DLL_LOCAL(...)
6692450 2742: ScanThreadFunc_DLL_LOCAL(...). Setting fIoctlRetStat = TRUE
6692470 2742: ScanThreadFunc_DLL_LOCAL(...)-> Doing IOCTL_M301_START_SCAN_THREAD. Flags: 10000
6692530 2742: SCAN_InitDevDrvrScanThread()-> Finished wait for fIOCTL_Scan_CallStarted == TRUE.
6692540 2742: SCAN_InitDevDrvrScanThread()-> Starting clock to wait for SCAN_MEM_ALLOC_SUCCESS == TRUE.
6692560 2742: SCAN_InitDevDrvrScanThread()-> Finished clock to wait for SCAN_MEM_ALLOC_SUCCESS == TRUE: 6692560
6692570 2742: SCAN_InitDevDrvrScanThread()-> Finished clock to wait for SCAN_MEM_ALLOC_SUCCESS == TRUE: 6692570
6692590 2742: SCAN_InitDevDrvrScanThread()-> RateSeenByDriver: 1000
6692610 2742: SCAN_InitDevDrvrScanThread()-> AdjustedRateSeenByDriver: 200 (rate / 5 if !SINGLE_CHAN_SCAN)
NOTE: even 1 channel in multi-chan mode requires chan-change and settling time.
NOTE: We divide by 5 because 5 convesions are thown away for each channel change for settling time.
6692620 2742: SCAN_InitDevDrvrScanThread()-> BoostRequestedByDLL: 20
6692640 2742: SCAN_InitDevDrvrScanThread()-> BoostUsedByDriver: 7
6692660 2742: SCAN_InitDevDrvrScanThread()-> SCAN_uiIRQ_Timeout_BeforeBoost (BEFORE ANY BOOST): 0.050 seconds
6692670 2742: SCAN_InitDevDrvrScanThread()-> SCAN_uiTimeScanIRQ_TimeoutLow (AFTER BOOST but before adjustment
to boost): 1.050 seconds
6692690 2742: SCAN_InitDevDrvrScanThread()-> SCAN_uiIRQ_Timeout_AfterBoostAdj (AFTER ADJUSTMENT to boost if
enabled): 1.050 seconds
6692710 2742: SCAN_InitDevDrvrScanThread()-> SCAN_uiIRQ_Timeout_FinalRateAdj (FINAL ADJUSTMENT to boost):
1.000 seconds NOTE: Value above may be eliminated in future. May be currently hard-coded to
1second to prevent timeout errors (due to Windows time-slicing), while still adjusting BOOST
to optimum value.
6692740 2742: SCAN_bChanCnt: 8 .
6692760 2742: SCAN_InitDevDrvrScanThread(...)-> SCAN_START_MODE_RUN
6692770 2742: SCAN_InitDevDrvrScanThread(...)-> Calling SCAN_SendStartToken()
6692790 2742: Entering SCAN_SendStartToken(...)
6692810 2742: SCAN_SendStartToken(...)-> CMND_SINGLE_CHAN_DIGIN_SCAN
6692820 2742: Exiting SCAN_SendStartToken(...). SUCCESS
6692840 2742: Exiting SCAN_InitDevDrvrScanThread(...). SUCCESS
6692860 2742: DLL_StartScan_DIO(...)-> SCAN_bChanCnt: 8 (ignored in single-chan scan mode), SO_bScanArg: 8
6692870 EXITING DLL_StartScan_DIO()-> Calling ShowLists().
6692890 DLL's copy of devices still in app's list - DEC:
0 10050 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
6692910 pLLABS_DeviceIDList_DLL_SHARED (all devices in shared memory - HEX):
2742 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Numbers in HEX. If upper bit set, Device is unplugged.
6692920 DLL's App-Handle List (all indexes currently owned by any app):
7B0130 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
6692940 EXITING DLL_StartScan_DIO()-> Back from calling ShowLists().
6692960 2742: DLL_StartScan_DIO(...)-> Device Driver Scan Thread startup SUCCESS.
6692970 2742: Exiting: DLL_StartScan_DIO(...). SUCCESS
6693201 ** ENTERING SP_SendScanWriteCmnd() for DevID: 10050, Command: 2, Argument: 0
6698598 2742: Entering DLL_EndScan_DIO(...)
6698618 2742: DevID: 0x2742
6698628 2742: DLL_EndScan_DIO(...)-> This is a digital-input type scan
6698649 2742: DLL_EndScan_DIO(...)-> SCAN_bActiveChans[bWhichDevIndex_SL]: 1.
6698669 2742: DLL_EndScan_DIO(...)-> This is a digital-input type scan
6698679 2742: DLL_EndScan_DIO(...)-> :
SCAN_fScanFlags: 0x15C003
SCAN_uiTailPtr: 21600
SCAN_uiHeadPtr: 22050
Total bytes read: 22050
Total Points read: 5512
points in buffer: 660
SCAN_bDriverCheckSum: 0xC
SCAN_bDeviceCheckSum: 0xB
SCAN_bMicrocode Wrap Flag: 0
6699099 2742: ScanThreadFunc_DLL_LOCAL(...)-> Back from IOCTL_M301_START_SCAN_THREAD
6699109 2742: ScanThreadFunc_DLL_LOCAL(...)-> SCAN_fScanFlags: 15C05B (hex)
6699119 2742: SCAN_START_TOKEN_SENT
6699139 2742: SCAN_THREAD_RUN_REQUEST
6699159 2742: SCAN_EXIT_REQUEST
6699169 2742: SCAN_MAIN_IRP_RETURNING
6699189 2742: SCAN_THREAD_EXITED_SUCCESS
6699209 2742: SCAN_WAITING_FOR_ASYNC_DONE
6699219 2742: SCAN_MEM_ALLOC_SUCCESS
6699239 2742: SCAN_DLL_STILL_READING
6699259 2742: RateSeenByDriver: 1000
6699269 2742: AdjustedRateSeenByDriver: 200 (rate / 5 if !SINGLE_CHAN_SCAN)
NOTE: even 1 channel in multi-chan mode requires chan-change and settling time.
NOTE: We divide by 5 because 5 convesions are thown away for each channel change for settling time.
6699289 2742: SCAN_bChanCnt: 8 (ignored in single-chan scan mode).
6699319 2742: ScanThreadFunc_DLL_LOCAL()-> BoostRequestedByDLL: 20
6699340 2742: ScanThreadFunc_DLL_LOCAL()-> BoostUsedByDriver: 7
6699360 2742: SCAN_InitDevDrvrScanThread()-> SCAN_uiIRQ_Timeout_BeforeBoost (BEFORE ANY BOOST): 0.050 seconds
6699370 2742: ScanThreadFunc_DLL_LOCAL()-> SCAN_uiTimeScanIRQ_TimeoutLow (AFTER BOOST but before adjustment
to boost): 1.050 seconds
6699390 2742: ScanThreadFunc_DLL_LOCAL()-> SCAN_uiIRQ_Timeout_AfterBoostAdj (AFTER ADJUSTMENT to boost if
enabled): 1.050 seconds
6699410 2742: ScanThreadFunc_DLL_LOCAL()-> SCAN_uiIRQ_Timeout_FinalRateAdj (FINAL ADJUSTMENT to boost):
1.000 seconds
NOTE: Value above may be eliminated in future. May be currently hard-coded to 1second to prevent
timeout errors (due to Windows time-slicing), while still adjusting BOOST to optimum value.
6699440 2742: ## FLAGS:
SCAN_uiURB_Stat_1: 0x40000000
SCAN_uiURB_Stat_2: 0x0
SCAN_uiURB_Stat_3: 0x0
SCAN_bURB_Canceled: 0x0
6699460 2742: SCAN_usPacketErrCnt: 0
6699470 2742: SCAN_usChksumErrCnt: 0
6699510 2742: SCAN_liScanThreadStartTime HighPart: 137, LowPart: -317712394
6699520 2742: SCAN_liScanThreadExitTime HighPart: 137, LowPart: -294040569
6699540 2742: SCAN_liScanFuncExitTime HighPart: 137, LowPart: -295440798
6699560 2742: Time elapsed before scan LOOP exited: 6.221907
6699570 2742: Time elapsed before scan THREAD exited: 6.613082
6699590 2742: Time taken for IRQ to return (not necessarily a timeout): 0.0600758(sec)
6699610 2742:
6699620 2742: ScanThreadFunc_DLL_LOCAL(...)-> Scan device was NOT stalled.
6699640 2742: ScanThreadFunc_DLL_LOCAL(...)-> Scan device has NOT been removed.
6699660 2742: ScanThreadFunc_DLL_LOCAL(...)-> Done IOCTL_M301_START_SCAN_THREAD
6699670 2742: Exiting ScanThreadFunc_DLL_LOCAL(...)
6699690 EXITING ScanThreadFunc_DLL_LOCAL()-> Calling ShowLists().
6699710 DLL's copy of devices still in app's list - DEC:
0 10050 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
6699720 pLLABS_DeviceIDList_DLL_SHARED (all devices in shared memory - HEX):
2742 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Numbers in HEX. If upper bit set, Device is unplugged.
6699740 DLL's App-Handle List (all indexes currently owned by any app):
7B0130 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
6699760 EXITING ScanThreadFunc_DLL_LOCAL()-> Back from calling ShowLists().
6699770 Entering DllEntryPoint()
6699790 Exiting DllEntryPoint point
Exiting 2742: It took 0.445941 seconds for thread to exit.
6699820 2742: Sending EndScan token.
6699840 2742: Entering SCAN_SendEndToken(...)
6699860 2742: Exiting SCAN_SendEndToken(...). SUCCESS
6699870 2742: DLL_EndScan_DIO(...)-> Scan Thread exited successfully.
6699890 2742: ** SCAN_usNumAttemptedCanceledIrps: 39 .
6699900 2742: ** SCAN_usNumSucceededCanceledIrps: 39 .
6699920 2742: RWOD(...)-> SUCCESSFUL READ:
SR_ReadCompleted: 0x1
SR_CntBytesRead: 32
SR_Status: 0x8B
SR_DrvrRetStatus: 0x1
6700411 Entering DllEntryPoint()
6700421 Exiting DllEntryPoint point
6701993 2742: RWOD(...)-> SUCCESSFUL READ:
SR_ReadCompleted: 0x1
SR_CntBytesRead: 32
SR_Status: 0x8B
SR_DrvrRetStatus: 0x1
6702023 2742: DLL_EndScan_DIO(...)-> Correct end-of-scan byte sequence echoed!.
6702033 2742: Setting SCAN_END_TOKEN_SENT.
6702053 2742: DLL_EndScan_DIO(...)->. Exiting with success
6703926 Entering DLL_ReleaseDeviceFromIDList(...)
6703946 Entering ReleaseDeviceFromIDList_LOCAL(...)
6703966 CheckAndSetDevIDAccessFlag(...)-> Setting ACCESS RESTRICTION FLAG -> pLLABS_DeviceIDList_DLL_SHARED[32].
6703986 2742: ReleaseDeviceFromIDList_LOCAL(...)-> Closing ahWritePipe.
6703996 2742: ReleaseDeviceFromIDList_LOCAL(...)-> Closing ahReadPipe.
6704016 2742: ReleaseDeviceFromIDList_LOCAL(...)-> Closing hDevHandles.
6704036 2742: ReleaseDeviceFromIDList_LOCAL(...) Removed and closed pipes for this device.
6704046 Exiting ReleaseDeviceFromIDList_LOCAL(...) SUCCESS
6704096 Entering DllEntryPoint()
6704106 DllEntryPoint()-> process detaching.
6704126 ### DllEntryPoint()-> Attempting to halt Device Disconnect thread.
6704146 EXITING ThreadFunc_DevConnectionStat()
6704186 ### DllEntryPoint()-> Device Disconnect thread has been stopped.
6704196 DllEntryPoint process detach - Before ANY list update - calling ShowLists()
6704217 DLL's copy of devices still in app's list - DEC:
0 10050 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
6704237 pLLABS_DeviceIDList_DLL_SHARED (all devices in shared memory - HEX):
2742 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Numbers in HEX. If upper bit set, Device is unplugged.
6704247 DLL's App-Handle List (all indexes currently owned by any app):
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
6704267 DllEntryPoint()-> calling CheckScanStatForProcessDetach()
6704287 DllEntryPoint()-> This is a precautionary measure.
6704297 ENTERING CheckScanStatForProcessDetach()
6704317 CheckScanStatForProcessDetach()-> No devices found scanning
6704337 2742: DllEntryPoint()-> calling ReleaseDeviceFromIDList_LOCAL[0]
6704347 2742: *** This is a precautionary process. The DLL will confirm that all of the
Device IDs allocated by APP have had their I/O pipes closed and memory deallocated.
6704367 Entering ReleaseDeviceFromIDList_LOCAL(...)
6704387 CheckAndSetDevIDAccessFlag(...)-> Setting ACCESS RESTRICTION FLAG -> pLLABS_DeviceIDList_DLL_SHARED[32].
6704397 2742: ReleaseDeviceFromIDList_LOCAL(...)-> ahWritePipe already closed for this device.
6704417 2742: ReleaseDeviceFromIDList_LOCAL(...)-> ahReadPipe already closed for this device.
6704437 2742: ReleaseDeviceFromIDList_LOCAL(...)-> hDevHandles already closed for this device.
6704447 2742: ReleaseDeviceFromIDList_LOCAL(...) Removed and closed pipes for this device.
6704467 Exiting ReleaseDeviceFromIDList_LOCAL(...) SUCCESS
6704487 DllEntryPoint()-> calling UnInitDevice
app's list index: 1, DLL's list index: 0. DevID: 10050
6704497 2742: Entering UnInitDevice(). usDevID: 10050. bWhichDevIndex_SL: 0
6704517 2742: Exiting UnInitDevice(). usDevID: 10050. bWhichDevIndex_SL: 0
6704537 DllEntryPoint process detach - After ANY list update - calling ShowLists()
6704547 DLL's copy of devices still in app's list - DEC:
0 10050 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
6704567 pLLABS_DeviceIDList_DLL_SHARED (all devices in shared memory - HEX):
2742 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Numbers in HEX. If upper bit set, Device is unplugged.
6704577 DLL's App-Handle List (all indexes currently owned by any app):
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
6704597 Exiting DllEntryPoint point