LL_USB.INI file usage

Information concerning .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.

[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=30

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 often 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 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

SS_dbgLvl=0	// Used only by the S1 type scan  0-5 valid values 



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.






//====================================
//====================================
// Following values should be set
// BY FACTORY ONLY
// StackedIrpCntOverride (default = 0) 
//====================================
//====================================
StackedIrpCntOverride=0 
		//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.






//=======================================
//=======================================
// 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. 

  // 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.

(use browser "back" button to go back to other locations)

lawsnlab@lawsonlabs.com
last modified: 4-24-09

Sample "Debug File" output

This log file created:  Tue Apr 07 07:40:23 2009
This DLL compilation date/time: Mar 24 2009, 15:04:05
This DLL version: 3,24,2009,0

InitDLL(...)-> parent window HANDLE: 0x11068E, Debug Level: 5

1187	Entering DLL_Init()
1187	DLL_Init()-> GOT from kernel uiProcessPriorityBoostGot: 0, from INI ProcessPriorityBoost: 0
1187	DLL_Init(...)-> DLL Name: LL_USB2k.DLL
1203	DLL_Init(...)-> Win Numeric Version: 0xA280105
1218	DLL_Init(...)-> Floating point info: In rare circumstances, a floating-point precision error can occur (Pentium)
1218	DLL_Init(...)-> Floating point info: In rare circumstances, a floating-point precision error can occur (Pentium)
1234	DLL_Init(...)-> User Name:  Tim
1234	DLL_Init(...)-> Windows Version Info:.
	 dwOSVersionInfoSize: 148 
	 dwMajorVersion: 0x5 
	 dwMinorVersion: 0x1 
	 dwBuildNumber: 2600 
	 dwPlatformId: Win32 on Windows NT 
	 szCSDVersion: Service Pack 2

1250	Entering GetWinVer()
1265	GetWinVer(..)-> Found OS to be Either WinXP or Win.NET

1281	DLL_Init(...)-> System Info:
	 wProcessorArchitecture: PROCESSOR_ARCHITECTURE_INTEL 
	 dwPageSize : 4096 
	 lpMinimumApplicationAddress: 0x10000 
	 lpMaximumApplicationAddress: 0x7FFEFFFF 
	 dwActiveProcessorMask: 3 
	 dwNumberOfProcessors: 2 
	 dwProcessorType: 586
	 dwAllocationGranularity: 65536 
	 wProcessorLevel  6,  (Processor name unavailable)
	 wProcessorRevision: 3846

 1296	DLL_Init()-> ProcessorNameString:
	Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz

1328	DLL_Init()-> Identifier:
	x86 Family 6 Model 15 Stepping 6

1343	DLL_Init()-> VendorIdentifier:
	GenuineIntel

1359	DLL_Init()-> Finished retrieving  CPU information from registry
1375	DLL_Ini(...)-> Calling DLL_SetPriorityMsgHandling_CPP()

1390	Priority messaging will be sent to Application callback... or just disregarded if one doesn't exist.
1406	
DLL_Init()->
App's ID List: 1816  
DLL's new copy of app's List: 1816  

1421	DLL_Init(...)-> Calling InitDLL().

1453	InitDLL(...)-> parent handle: 0x11068E
1468	LOCAL_CreateFileMappings(...)-> mapped file mmfSharedDebugData_RW_LL already exists. This is not an error.
1484	LOCAL_CreateFileMappings(...)-> s_hFileMapDebugHANDLE_RW_LL: 0x2C
1500	LOCAL_CreateFileMappings(...)-> success creating mapping for pszDebugStrings_DLL_SHARED_RW_LL
1515	LOCAL_CreateFileMappings(...)-> s_hFileMapDebugHANDLE_SCAN_LL: 0x198
1531	LOCAL_CreateFileMappings(...)-> success creating mapping for pszDebugStrings_DLL_SHARED_SCAN_LL
1562	LOCAL_CreateFileMappings(...)-> mapped file mmfSharedDebugDataX2 already exists. This is not an error.
1578	LOCAL_CreateFileMappings(...)-> s_hFileMapDebugHANDLE_2: 0x19C
1593	LOCAL_CreateFileMappings(...)-> success creating mapping for pszDebugStrings_DLL_SHARED_RSD_LL
1609	LOCAL_CreateFileMappings(...)-> mapped file mmfSharedDebugDataMisc already exists. This is not an error.
1625	LOCAL_CreateFileMappings(...)-> s_hFileMapDebugHANDLE_MISC_LL: 0x1A0
1640	LOCAL_CreateFileMappings(...)-> success creating mapping for pszDebugStrings_DLL_SHARED_MISC_LL
1671	CreateFileMappings(...)-> s_hFileMapAppHANDLE: 0x1A4
1687	CreateFileMappings(...)-> success creating mapping for lpListViewAppHANDLE
1703	CreateFileMappings(...)-> s_hFileMapGUID: 0x1A8
1718	CreateFileMappings(...)-> success creating mapping for lpListViewGUID
1734	InitDLL(...)-> pusAppDevListCopy[0]: 0x1816
1750	InitDLL(...)-> 2B-pLLABS_DeviceIDList_DLL_SHARED[0]: 0x0
1765	InitDLL(...)-> going to GetDeviceIDList(...)
1781	Entering GetDeviceIDList(...)
1812	CheckAndSetDevIDAccessFlag(...)-> Setting ACCESS RESTRICTION FLAG -> pLLABS_DeviceIDList_DLL_SHARED[32].
1828	GetDeviceIDList(...)-> Probing for attached devices
1843	Entering GetUsbDeviceCnt(...)

1859	GetUsbDeviceCnt(...)-> Last Item Located
1984	GetUsbDeviceCnt(...)-> Number of devices: 0
2000	Leaving GetUsbDeviceCnt(...)  SUCCESS

2015	GetDeviceIDList(...)-> GetUsbDeviceCnt() Found the following after calling SP_GetRegDevList():
2031	GetDeviceIDList(...)-> All devices currently in pDeviceNameList_DLL_SHARED (showing index):
2046	AFTER finding all available devices in GetDeviceIDList(). Ready to call ShowLists()
2078	Entering ShowLists()
2078	
2109	DLL's copy of devices still in app's list (showing offsets into list) - HEX: 
		1816  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
2140	pLLABS_DeviceIDList_DLL_SHARED (all devices in shared memory (showing offsets into list) - HEX): 
		0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
2156	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  

2171	Ready to exit GetDeviceIDList(). Ready to call ShowLists()
2187	Entering ShowLists()
2203	
2234	DLL's copy of devices still in app's list (showing offsets into list) - HEX: 
		1816  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
2250	pLLABS_DeviceIDList_DLL_SHARED (all devices in shared memory (showing offsets into list) - HEX): 
		0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
2265	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  

2281	nGetDeviceIDList(...)-> Clearing ACCESS FLAG.
2296	Exiting GetDeviceIDList(...)  SUCCESS

2312	InitDLL(...)-> back from GetDeviceIDList(...)
2343	InitDLL(...)-> bNumDevicesInSharedList: 0
2359	Exiting InitDLL(...)-> SUCCESS

2375	Exiting DLL_Init(...)-> SUCCESS

2390	#### SP_InitAllDevices(...)-> pDevList : 6166, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
2406	#### SP_InitAllDevices(...)-> pdblDevRate : 100.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, 
2421	SP_InitAllDevices(...)-> Searching for connected devices
2453	ENTERING InstanceInitDeviceList_LOCAL(...)
2468	CheckAndSetDevIDAccessFlag(...)-> Setting ACCESS RESTRICTION FLAG -> pLLABS_DeviceIDList_DLL_SHARED[32].
2484	ENTERING InstanceInitDeviceList_LOCAL().
2500	BEFORE comparing app's list with shared list in InstanceInitDeviceList_LOCAL()
		App's ID List: 1816  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  

2515	Calling ShowLists().
2531	Entering ShowLists()
2546	
2562	DLL's copy of devices still in app's list (showing offsets into list) - HEX: 
		1816  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
2578	pLLABS_DeviceIDList_DLL_SHARED (all devices in shared memory (showing offsets into list) - HEX): 
		0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
2609	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  

2625	InstanceInitDeviceList_LOCAL(...) -> ####  devices: 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
2640	InstanceInitDeviceList_LOCAL(...) -> Dev: 0x1816 not found in shared list.
2656	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 1
2671	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 2
2687	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 3
2703	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 4
2718	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 5
2750	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 6
2765	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 7
2781	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 8
2812	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 9
2828	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 10
2859	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 11
2890	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 12
2921	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 13
2937	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 14
2968	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 15
3000	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 16
3015	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 17
3031	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 18
3062	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 19
3078	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 20
3109	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 21
3140	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 22
3156	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 23
3187	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 24
3203	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 25
3234	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 26
3265	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 27
3281	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 28
3312	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 29
3328	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 30
3343	InstanceInitDeviceList_LOCAL(...) -> No device in app's list at index: 31
3375	InstanceInitDeviceList_LOCAL--> ShowLists() MARK-1 
3390	Entering ShowLists()
3406	
3437	DLL's copy of devices still in app's list (showing offsets into list) - HEX: 
		1816  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
3453	pLLABS_DeviceIDList_DLL_SHARED (all devices in shared memory (showing offsets into list) - HEX): 
		0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
3468	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  

3500	InstanceInitDeviceList_LOCAL(...)-> Clearing ACCESS FLAG.
3531	InstanceInitDeviceList_LOCAL--> ShowLists() MARK-2 
3546	Entering ShowLists()
3578	
3609	DLL's copy of devices still in app's list (showing offsets into list) - HEX: 
		0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
3625	pLLABS_DeviceIDList_DLL_SHARED (all devices in shared memory (showing offsets into list) - HEX): 
		0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
3656	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  

3671	InstanceInitDeviceList_LOCAL--> ShowLists() MARK-3 
3703	Entering ShowLists()
3718	
3750	DLL's copy of devices still in app's list (showing offsets into list) - HEX: 
		0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
3781	pLLABS_DeviceIDList_DLL_SHARED (all devices in shared memory (showing offsets into list) - HEX): 
		0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
3796	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  

3828	READY TO EXIT InstanceInitDeviceList_LOCAL().
3843	AFTER comparing app's list with shared list in InstanceInitDeviceList_LOCAL()
App's ID List:: 0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  

3890	Calling ShowLists().
3906	Entering ShowLists()
3937	
3953	DLL's copy of devices still in app's list (showing offsets into list) - HEX: 
		0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
3968	pLLABS_DeviceIDList_DLL_SHARED (all devices in shared memory (showing offsets into list) - HEX): 
		0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
4000	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  

4031	#### SP_InitAllDevices(...)-> pDevList : #2 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
4046	#4  -  0 
4078	#### SP_InitAllDevices(...)-> pDevList : #3 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
4093	SP_InitAllDevices--> ShowLists() MARK-3 
4109	Entering ShowLists()
4140	
4156	DLL's copy of devices still in app's list (showing offsets into list) - HEX: 
		0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
4171	pLLABS_DeviceIDList_DLL_SHARED (all devices in shared memory (showing offsets into list) - HEX): 
		0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
4203	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  

4218	#5  -  0 
4234	#### SP_InitAllDevices(...)-> pDevList : #5 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
4265	#7  -  0 
4296	SP_InitAllDevices--> ShowLists() MARK-5 
4328	Entering ShowLists()
4343	
4375	DLL's copy of devices still in app's list (showing offsets into list) - HEX: 
		0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
4390	pLLABS_DeviceIDList_DLL_SHARED (all devices in shared memory (showing offsets into list) - HEX): 
		0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
4421	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  

4437	#8  -  0 
4468	#11  -  0 
4484	#### SP_InitAllDevices(...)-> pDevList : #6 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
4500	SP_InitAllDevices--> ShowLists() MARK-6 
4531	Entering ShowLists()
4546	
4578	DLL's copy of devices still in app's list (showing offsets into list) - HEX: 
		0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
4593	pLLABS_DeviceIDList_DLL_SHARED (all devices in shared memory (showing offsets into list) - HEX): 
		0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
4625	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  

4656	Entering DllEntryPoint()
4671	DllEntryPoint()-> DLL_THREAD_DETACH.
4703	Exiting DllEntryPoint point

4734	ENTERING ThreadFunc_DevConnectionStat()
4859	#>#>#> ThreadFunc_DevConnectionStat()-> First reading of registry
4875	#>#>#> ThreadFunc_DevConnectionStat()-> Setting dwDevStat = ConnectionStat(0x17F) value from registry
6484	Entering DllEntryPoint()
6515	DllEntryPoint()-> process detaching.
6531	###  DLL_PROCESS_DETACH_Handler()-> Attempting to halt Device Disconnect thread.
6609	EXITING ThreadFunc_DevConnectionStat()
6656	###  DLL_PROCESS_DETACH_Handler()-> Device Disconnect thread has been stopped.
6671	DLL_PROCESS_DETACH_Handler process detach - Before ANY list update - calling ShowLists()
6703	Entering ShowLists()
6718	
6750	DLL's copy of devices still in app's list (showing offsets into list) - HEX: 
		0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
6781	pLLABS_DeviceIDList_DLL_SHARED (all devices in shared memory (showing offsets into list) - HEX): 
		0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
6812	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  

6828	DLL_PROCESS_DETACH_Handler()-> calling CheckScanStatForProcessDetach()
6859	DLL_PROCESS_DETACH_Handler()-> This is a precautionary measure.
6890	ENTERING CheckScanStatForProcessDetach()
6906	CheckScanStatForProcessDetach()-> No devices found scanning
7937	DLL_PROCESS_DETACH_Handler()-> No devices found that needed handles closed or removed from mem-mapped files.

7953	DLL_PROCESS_DETACH_Handler process detach - After ANY list update - calling ShowLists()
7968	Entering ShowLists()
8000	
8015	DLL's copy of devices still in app's list (showing offsets into list) - HEX: 
		0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
8046	pLLABS_DeviceIDList_DLL_SHARED (all devices in shared memory (showing offsets into list) - HEX): 
		0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  
8078	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  


*****************************************************
******* MEM-MAPPED ReadWriteDevice START ************
x	
******* MEM-MAPPED ReadWriteDevice END **************
*****************************************************


**************************************************
******* MEM-MAPPED ReadScanData START ************
BYTE VALS: clock(), chan, hiByte, midByte, loByte, digin

x	
******* MEM-MAPPED ReadScanData END ************
************************************************


*************************************************
******* MEM-MAPPED SCAN THREAD START ************
as referenced below:
  [SBCT:ScanByteCntTotal] [CBC:CurByteCnt] [CLRI:CurLocalReadIndex] [BInBuff:BytesInLocalBuff [HDP:ScanDataBuffHead_GLOBAL] 
  [TP:ScanDataBuffTail_GLOBAL] [t29:DataReadBuff_LOCAL[29]] [t28:DataReadBuff_LOCAL[28-bCurLocalReadIndex]] 
x	
******* MEM-MAPPED SCAN THREAD END **************
*************************************************


***************************************************
******* MEM-MAPPED MiscFunctions START ************
x	
2453	12345	SP_InitAllDevices()-> calling InstanceInitDeviceList_LOCAL()
4046	6166	SP_InitAllDevices()-> This Device ID failed enumeration
******* MEM-MAPPED MiscFunctions END **************
***************************************************

8093	Exiting DLL_PROCESS_DETACH_Handler point

back to DebugLvl entry explanation

   back to INSTALL.HTM (Installation documentation file)

   lawsnlab@lawsonlabs.com
   last reviewed/modified: 4-10-09 (Tim Van Dusen)