none
Bluetooth (HCRP) LanguageMonitor RRS feed

  • Question

  • I am having a LanguageMonitor which is based on PJLMON sample. My LanguageMonitor is being used with USB based printers. Currently we are adding a new Bluetooth printer (incl. HCRP support). The LanguageMonitor is working just fine on Windows 7 on USB as well as Bluetooth ports (e.g. BTH001). Furthermore the same LanguageMonitor is also working just fine on Windows 8 & 10 on USB ports. But it isn't working on Bluetooth ports (e.g. BTH001).

    The problem is caused in my LMonOpenPortEx() function when I call pfnOpenPort() of lower layer driver. In case of Bluetooth the pfnOpenPort() call fails while it succeeds on Windows 7 and on USB ports. Unfortunately GetLastError() doesn't return consistent data. 

    If I use virtual COM ports for the Bluetooth communication then a pfnOpenPort() call succeeds on Windows 7, 8 and 10.  

    I don't know how I can debug the pfnOpenPort() in more detail. Do I need to install checked build of the OS and debug the issue with WinDbg or Kernel Debugger? Is there any easier way to figure out why pfnOpenPort() fails?

    Thank you,
    Phil

    Friday, July 22, 2016 4:07 PM

Answers

  • I have fixed the Bluetooth printing by porting my LanguageMonitor from the old InitializePrintMonitor function to InitializePrintMonitor2. This also had an impact on my OpenPortEx() function since this change required that I call OpenPort() on the port monitor with 3 arguments instead of 2.

    It seems that Windows 8 and Windows 10 have an issue with printing over Bluetooth (BTHPRINT) when calling OpenPort() with 2 arguments on the port monitor. It is working just fine on Windows 7.

    Phil

    Thursday, August 4, 2016 10:42 AM

All replies

  • I have installed the kernel debugger and I have a little bit more information. Unfortunately I haven't been able to resolve the issue yet.

    My LanguageMonitor is calling pfnOpenPort() which ends up in localspl!DlOpenPort. One of the passed arguments is "BTH001" which is OK. Next localspl!GetDlPointers gets called. Within GetDlPointers wcschr("BTH001", ",") gets called and then wcsnicmp("BTH001", "USB", 3) which will return not equal and thereafter last error is set to 0x32 (ERROR_NOT_SUPPORTED). This will fail the initial pfnOpenPort call. 

    In case of virtual COM ports the wcschr("COM5: ,", ",") will find the character and therefore there isn't a wcsnicmp call. But it is working just fine with virtual ports. 

    The pfnOpenPort is working just fine with USB ports on a Windows OS versions, but it only works for BTH on Windows 7. 

    I don't know where the wcsnicmp gets the "USB" from. Maybe the registry? Or is this an Windows issue?

    Thank you,
    Phil



    Monday, August 1, 2016 2:43 PM
  • I wonder if the issue is being caused by using the old InitializePrintMonitor function and MONITOREX approach instead of InitializePrintMonitor2 and MONITOR2.

    I have started converting to InitializePrintMonitor2 and MONITOR2. There are still some issues, but the pfnOpenPort call ends up in usbmon now. Actually it ends up in usbmon whether I am using USB or BTH ports. This doesn't sound correct, isn't it?

    Thank you,
    Phil


    Tuesday, August 2, 2016 9:19 PM
  • I have fixed the Bluetooth printing by porting my LanguageMonitor from the old InitializePrintMonitor function to InitializePrintMonitor2. This also had an impact on my OpenPortEx() function since this change required that I call OpenPort() on the port monitor with 3 arguments instead of 2.

    It seems that Windows 8 and Windows 10 have an issue with printing over Bluetooth (BTHPRINT) when calling OpenPort() with 2 arguments on the port monitor. It is working just fine on Windows 7.

    Phil

    Thursday, August 4, 2016 10:42 AM