LL_USB.INI file usage

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 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 setting this entry to a non-zero value before changing the ScanSystemBoostLevel previously discussed.

post 2.7.2008.0 DLL version:
If this entry is non-zero, the DLL will make further adjustments to it based on several scan setup parameters in a way 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 use a default value of 10.

pre 2.7.2008.0 DLL version:
If this value is 0, the DLL will use a default stacking of 20 IRPs. Otherwise it will use the entered value, up to a maximum of 40.

post 2.7.2008.0 DLL version:
This value can be interpretted as "requested seconds worth of stacked IRP's." If set to a non-zero value, the driver will take that value, divide it by 10, and attempt to stack the number of IRP's required for that many seconds worth of stacked IPR's. For example an entry of 30 can yield approximately 3 seconds worth of IRPs for a single channel scan at 100Hz. The number of stacked IRP's for that yield will be 40. For that same scan at 50Hz, the driver would stack 21 IRP's. If set to zero, our driver will adjust the amount of stacked IRP's in a way to obtain as close as possible to one second worth of stacked IRP's.

pre 2.7.2008.0 DLL version:
There is no further special handling of this 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.

back to main page Table of Contents (use browser "back" button to go back to other locations)

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

back to DebugLvl entry explanation
back to API.HTM (main API index file)
back to INSTALL.HTM (Installation documentation file)

lawsnlab@lawsonlabs.com
last reviewed/modified: 8-13-03 (Tim Van Dusen)