Full Demo application freezes when using the DTWAIN64u.dll (HP 7000 S3)

[sean-neeley]

FullDemo.zip

We are using an HP Scanjet 7000 s3. The attached sample program works great when running as "Debug - Any CPU", which uses DTWAIN32u.dll. However if you take the same project and run as "Debug - x64" which uses DTWAIN64u.dll the application freezes during the HP "Processing Images" dialog. We our trying to build a 64bit application and this is a show stopper for us.

To recreate, run the attached project as Debug - x64.
Put about 5 sheets of paper in the document feeder. Select the source, then Acquire Test -> Acquire Buffered from the menu Move the mouse outside of the application window right away (not sure if this is really needed) The HP scanner dialog will show it is acquiring the images, and feeds the paper through. Next the HP scanner dialog will show it is Processing the images, but will hang. If you run the same steps above with the "Debug - Any CPU" and DTWAIN32u.dll, it will not hang in this spot and will populate the document tree view with an entry for each page scanned.

Unfortunately we do not have any other model scanners with 64bit TWAIN drivers to test this. It could be only an issue that happens with the HP drivers, but I'm not sure. I believe you said you had an HP scanner.

Thank you

[dynarithmic]

What happens if you acquire using native mode instead of buffered?

I will see if there is an issue with the buffered mode if the native mode goes through ok.

[dynarithmic]

It looks like the native mode should work for you, since buffered mode is a little more complex in terms of memory management.

Do you have another application, preferably one not written by HP, that accesses the scanner and does transfers using the 64-bit driver? If you do, and you can control whether you can acquire using native or buffered, that would be a good test to see if there is an underlying problem with DTWAIN and 64-bit buffered transfers.

[sean-neeley]

Thank you for the quick reply. We will give this a try and report back next week.

[dynarithmic]

I will be making a few changes for the buffered mode. When the changes are ready, I will make them available in the development branch of the twain_library_source repository. You can test them to see if any difference is made when using the HP.

I will let you know when the new DLL's become available.

[sean-neeley]

OK Thanks Paul!

[dynarithmic]

I just updated the development branch with version 5.3.0.1 of DTWAIN. The release_libraries.zip contains the latest version.

The changes are to address a potential issue with the buffered transfer calling the TWAIN system to query when there are more pages to transfer. Possibly this is the issue you encountered, but not sure until you test the new version.

This was tested against a Plustek scanner using 64-bit drivers, and the sample TWAIN Working Group 64-bit driver. Both scanners work with 5.3.0.0, but I found issues without showing the scanner user-interface in buffered mode, and the TRUE/FALSE "close source when UI is closed" parameter to DTWAIN_AcquireBufferedEx() that could affect things.

[sean-neeley]

OK, I download your release_libraries.zip and tried the latest 64bit DLL. Unfortunately the test application still freezes. I tried the following:

• Switched code to AcquireNativeEx. No luck
• Tried with the close source option both TRUE and FALSE. No luck
• Removed the callback function from the code. No luck

Application still freezes on the "Processing Image(s)" dialog. If I pause the debugger, it pauses on the AcquireBufferedEx() line.

I downloaded Twacker_64 to test. I set it to hide UI and use Memory for the acquire.

It works without hanging and "Processing Image(s)" appears and goes away as expected.

Is there anything I can try next? Can I create any logs to help you?

[dynarithmic]

Are you acquiring with or without the UI when you're using DTWAIN? If you are acquiring without the UI, please try this with the UI being shown.

Did you also try the DTWDEMO program? Twacker is written in C, just like the DTWDEMO program. Make sure the issue has nothing to do with .NET.

[dynarithmic]

As to logs, you can use DTWAIN_SetTwainLog and turn on all logging and log to a file (the DTWDEMO program has such an option).

One difference in Twacker and DTWAIN is that Twacker does the minimal setup to scan an image -- it really isn't designed to exercise the scanner's capabilities as DTWAIN attempts to do. Quite possibility the querying / setting of a capability is exposing something in the HP scanner that shouldn't occur. It wouldn't be the first time this has happened (the Samsung Galaxy TWAIN driver had several issues where it wasn't following the TWAIN specifications).

[dynarithmic]

Also, if you are familiar with C++ and debugging on the native side of the app, you could debug into AcquireBufferEx(). To do that, you should use the dtwain32ud.cs file, make sure that dtwain32ud.dll is available, and try to debug into the native code.

The debug dlls are found here, and the source here.

The source file that may be of interest is ctltr031.cpp, where a bulk of the buffered transfer logic is being done. Granted it is a lot of code, but I think you could see if the hanging of the app is occurring within that file.

[sean-neeley]

Enabling UI doesn't help. I created logs for it working with the 32bit DLL and it not working with the 64bit DLL. showUI was false for these logs.

DTWAIN32.LOG DTWAIN64.LOG

I'm slightly familiar with C++ and could probably debug it. However I'm not sure of how to debug ctlr031.cpp from my C# project. Or would I locate a C++ DTWAIN demo app and debug in there?

[dynarithmic]

Did you try the DTWDEMO.EXE program? Still not sure if this is a C# / .NET issue or a general issue.

[sean-neeley]

I downloaded DTWDEMO.EXE, but it is 32bit. It works.

Is there a 64bit version somewhere?

[dynarithmic]

I placed the demo programs in the source repo. You can get it here.

[dynarithmic]

Looking at the DTWAIN64.LOG, there is a failure of setting the feeder. If you search the log file for TWCC_CAPBADOPERATION, you should see it around line 34012:

ConditionCode=14 TWCC_CAPBADOPERATION

Preceeding this, an attempt to set the feeder was done, but resulted in failure. You can see the previous attempt to set the feeder, and the failure detected around line 33896:

[2023-01-31 16:32:16] Output: return code from DSM=1 (TWRC_FAILURE)

and the TWCC_CAPBADOPERATION is what was returned when querying as to why the setting of the feeder failed. Note that in the 32-bit log, around the same sequence of calls, there is no failure in setting the feeder.

As demonstrated by the logs, there is a difference in the way the HP 32-bit driver and 64-bit driver behave, and it is not a straight port of the driver code from 32-bit to 64-bit. I also saw that that the 32-bit driver has 117 capabilities, while the 64-bit driver has 118 capabilities. There is a ICAP_IMAGEMERGE capability that doesn't exist in the 32-bit version. It is strange why the same hardware would have differences in the driver like this.

Unfortunately, I don't have this scanner model. So debugging the issue would be a very slow process, unless I get the scanner here and test it. Probably wouldn't take me long to figure out a workaround, but it is very difficult without the hardware.

[dynarithmic]

To debug, you could load the dtwain_5_vs2019.sln into Visual Studio, and attach to the running C# process. Then you should be able to set a breakpoint in the C++ code (DTWAIN_AcquireNativeEx() found in cltacquirenative.cpp would be a starting point.

[dynarithmic]

The new demo programs include the changes that were made in 5.3.0.1, so the issue I identified a few days ago is accounted for if you get the demo programs at the previous link.

The twain_library repository is still on 5.3.0.0, so the demo programs located there in the zip file won't have these changes.

[sean-neeley]

I'm having trouble running the DTWDEMO64.EXE. I get this error:

I downloaded and installed the MS Visual Studio x64 redistributable and rebooted, but that did not help. I've never seen that error before. Any ideas what I need to run it?

[dynarithmic]

I updated the development branch with the lastest 64-bit demo. Please make sure that the DLLs and EXE's used are from this archive in the 64bit_FullDemo.zip file.

Also, I took another look at the 32-bit DTWAIN log file you produced, and the version of DTWAIN that is running for 32-bit was 5.2.0.8. Since this is an older version, did you make sure that version 5.3.0.0 for 32-bit also runs correctly?

[sean-neeley]

OK, thanks for the help. I got DTWDEMO64.exe to run using your 64bit_FullDemo.zip. It has the hanging issue. One thing I noticed when testing it. After it hangs, if I right click on the application in the Windows taskbar and choose "Close Application", suddenly it unfreezes and is able to continue operating OK. I'm attaching a log of this. DTWAIN64new.log We noticed something similar in our C# app, where we would move the mouse or simulate a mouse cursor move and it would unfreeze. I tried this mouse hack in the FullDemo app and it didn't do anything though.

Regarding the 32-bit DTWAIN log. I created a new log with the 5.3.0.0 for 32-bit. It ran fine, although it seemed a lot slower than the 64-bit application when selecting a source. I do have more 32bit sources on my test system though. I'm including the log below. It is from the C# Full Demo. DTWAIN32new.log

Last, I grabbed the DTWAIN dll source and tried to compile it so I could debug it. However the project seems to require some library called "boost" that I do not have and is not part of the project or visual studio. Do I need to download from boost.org?

[dynarithmic]

1) Looking at the 64-bit log, it is the setting of the feeder using the CAP_FEEDERENABLED capability that seems to be glitching things. Then as you mentioned, it looks like the scan goes through afterwards, at least the scanner responds. I will try to see if there is anything strange that can occur if the setting of the feeder fails (it shouldn't fail, as the 32-bit version has no issues doing this).

2) To rebuild the source, you will need the boost library, as described here.

You also will need to set the BOOST_INCLUDE_DIR environment variable before starting Visual Studio. The 7-zip and DirHash programs are not important in building the library (in your case) -- they just provide a way to package up and compute the hash code of the generated output files.

[dynarithmic]

I am speculating that it has something to do with the message processing and the UI that HP uses for 64-bit. The strange behavior of the scan going through afterwards is unusual.

I may be able to get my hands on a HP 5000 S4, which may use the same base driver as the 7000 S3. I went to the HP website to see what driver the 5000 uses, and the version number of the latest drivers for both 5000 S4 and 7000 s3 are "41.x".

If my speculation is correct, that the driver's base code is the same, then I may be able to duplicate the issue here. However, I won't really be able to do anything until I can confirm I can get the scanner, and have it in-house. That may take more than a week.

The only other option (and this has been done before, but this was when DTWAIN was commercial) is for the user to send the scanner to us and we fix the issue. It usually takes a very short time, since we are familiar with the code and know what to look out for and if need be, write any workarounds for bugs that may be in the scanner driver. Not sure if you want to go this route, but let me know.

[sean-neeley]

OK thank you. I am going to see how far I can get with debugging myself. If I'm unable to locate the problem, we should be able to send you a spare 7000 s3 that we have. Are you located in the united states?

[dynarithmic]

Yes, I'm here in the US. Just let me know when/if you will send the scanner over.

In the meantime I may have to get this model or one based on it in-house on a permanent basis. I have for 64-bit scanning a Plustek and Fujitsu scanner for ADF/duplex testing, but the HP scanner I have doesn't have a 64-bit driver, so can't use it for 64-bit access.

[dynarithmic]

Good news:

I landed getting an HP 7000 scanner. I will probably also get the HP 5000 in-house. I should get it by the end of this week, and will probably be ready to test sometime next weekend.

[sean-neeley]

Ok, that is awesome. I'm still working on getting the DTWAIN dll to compile. You would definitely be able to figure out the issue a lot quicker than I could. I appreciate the help.

[dynarithmic]

Yes, hopefully I can duplicate the issue, and the fix will not be that difficult.

To get the DLL built, it is basically 4 steps:

1) Get the boost library for your Visual Studio platform setting. The default platform is 2015 (v140), so you can install the libraries (32 and 64 bit) that have file names ending with "14.0-32" and "14.0-64".

If you happen to not have the v140 runtime platform installed, then you should get the other 32 and 64 bit boost libraries that fit the platform you have (for example, Visual Studio 2019 always asks if you want to upgrade to v142 when you load a project with 2015 components -- you don't have to do this, but just in case you do...).

The platform for v142 is 14.2, for v141 it is 14.1, etc. So download the boost files that are named appropriately.

When installing boost, make sure that the 64-bit and 32-bit versions are installed in the same directory (the installation will also add the header files). So if you installed boost in C:\boostlibs, then you should see a boost directory under C:\boostlibs, and a lib32-msvc-14.0 and a **lib64-msvc-14.0" directory (assuming you are using the v140 platform).

2) Set the environment variables:

Using the example above, you can use the command-line, or use the Settings dialog in Windows OS. Here is the command:

SET BOOST_INCLUDE_DIR=c:\boostlibs SET BOOST_LIBRARY_DIR_V140_32=c:\boostlibs\lib32-msvc-14.0\ SET BOOST_LIBRARY_DIR_V140_64=c:\boostlibs\lib64-msvc-14.0\

3) Start Visual Studio 2019 (or 2022) and load the dtwain_5_3_vs2019.sln as the solution file. You may be prompted to upgrade to 142 platform. If you have v140 installed, then do not upgrade, if you don't have it installed and need to upgrade to match what platform you do have installed, then make sure your boost files match the platform you are upgrading to (see step1).

4) On the Visual Studio main menu, choose "Build -> Batch Build" and select all of the projects named DTWAIN_DLL and DTWDEMO. Then choose "Build" from that same dialog.

That's about it. Any errors you get when building will be for the 7-zip utility and the DirHash utility not being found, but that isn't going to affect the build of the dlls. Once built, the DLLs will be in a binaries directory under the source directory.

Hope that helps.

[sean-neeley]

OK, I'm using platform v143. I compiled boost 1.81. It has a little different directory structure. All of the libraries seem to be in the folder c:\boost_1_81_0\staged\lib. I opened the DTWAIN project and upgraded to 143 when prompted. I then did the batch build and selected all. It took an hour or so and then I end up with these two errors:

These are the closest matching library files on disk:

It looks like the only difference in the filename is "sgd" vs "gd" and I'm not sure why. Could I just rename it on disk? Or should I change it somewhere in the project? Or should I have done something different when building boost?

Thanks

[dynarithmic]

I am currently using boost 1.80. If the other DLL's built without error, possibly this is missing from the list of binaries that were built for version 1.81. On my system, I have this file for platform v143:

libboost_filesystem-vc143-mt-sgd-x32-1_80.lib

I haven't tried to build 1.81 and VS 2022, so I am not aware of this issue. I have used VS 2019 and boost 1.80 without an issue. I will download it to see if that file is missing for VS 2022.

In the meantime, you can use the 64-bit DLL's (if they built correctly), or if you want to try to build everything again, you can try this:

Since you have the platform set to V143, what you could do is go to each of the individual project files in the Solution (go to the Solution Explorer, and expand everything), and set the compiler to

ISO C++17 Standard (/std:c++17)

To get to this setting, highlight the project in solution explorer, right click, select "Properties".
Then select C/C++ -> Language -> C++ Language Standard

Then rebuild. What this will do is remove the dependency of boost filesystem from DTWAIN. The reason why there is a dependency right now is that the v140 and v141 platforms are not C++17 compliant, and that is minimum required to have built-in filesystem support in C++.

You will need to do this for each of the following projects:

DTWDEMO cryplib all of the FreeImage projects (FreeImageLib, LibJPEG, LibJXR, etc.) DTWAIN_DLL

Once you change the compiler compliancy in each one, then you can do a rebuild.

[dynarithmic]

I just downloaded boost 1.81 for platform v143, and the file is included in the lib folder:

 Directory of C:\boost_1_81_0\64\lib64-msvc-14.3

12/08/2022  05:00 PM         8,069,770 libboost_filesystem-vc143-mt-sgd-x64-1_81.lib

This is only for 64-bit. I will check the 32-bit version and see what happens on a rebuild using VS 2022 .

[sean-neeley]

OK, so all of my boost library files have "-gd-" or "-mt-" in them. I searched for info on this and the "-sgd-" is for a statically linked build of the library. So somehow I missed an option to build statically linked libraries. I'll look into it tomorrow. I can also try your idea to skip using boost. Thanks again.

UPDATE: I think I need to use 'b2 link=static' when building the boost libs

[dynarithmic]

ok. I only use the boost binaries for Windows, and not need to rebuild them. But nothing wrong in attempting to build the boost libs yourself. The last time I had to build them was for a Linux port of DTWAIN (which is on hold right now).

Also, I was able to build using VS 2022 using v143 and C++17. However there is a coding change in some third-party imaging code you will need to make. You can pick up the latest source in the development/source repo.

If you are familiar with C++ and smart pointers, the issue is that the old imaging code uses std::auto_ptr, and this class was removed from C++17, so the C++17 build failed. This had to be changed to unique_ptr.

[sean-neeley]

Thanks I did run into that compiler issue and didn't know what to do. I'll try the latest source repo.

[sean-neeley]

Hi, I tried the new source repo and deleted my boost folder and changed every project to use ISO C++17 Standard (/std:c++17). However now I get compiler errors for missing boost includes. Do I need to keep around the boost folder for the includes? Example includes that are flagged:

#include <boost/tokenizer.hpp>
#include <boost/algorithm/string/join.hpp>
#include <boost/algorithm/string.hpp>
#include <boost/uuid/uuid.hpp>
#include <boost/uuid/uuid_generators.hpp>
#include <boost/uuid/uuid_io.hpp>
#include <boost/format.hpp>

[dynarithmic]

Yes, you need to keep the boost include directories.

[dynarithmic]

OK, I received the 7000 S3 scanner today and did some rudimentary testing. Here are my observations:

1) I used DTWDEMO64UD.exe, the debug version of the DTWDEMO app for 64-bit. I tested just a single page.

2) When opening the HP driver (DTWAIN_OpenSource), the driver will throw an exception with the following error: Exception thrown at 0x00007FF8EFBCCD29 in DTWDEMO64UD.exe: Microsoft C++ exception: HP::Pdsmq::Common::FileNotFoundException at memory location 0x000000EE487E70E0. ERROR: Fail creating Settings class: No factory settings file found This exception doesn't stop the application, just something that I noticed. So I ignored all of those exceptions and continued.

3) In the DTWDEMO app, I chose to scan using no user interface, made sure the document feeder was used, and buffered transfer. The scan for me went through, but there is something that annoys me with the HP driver, and possibly this is what is happening on your end:

After obtaining all of the transferred strips, the HP Scan Utility application opens up. For me it opened, but I have no idea what would happen on a system where the HP app wasn't installed, had trouble starting, etc. I don't know a workaround to turn off the way this woks, but I can imagine the issues if after the scan, something hinders that application from starting.

What's troublesome is that while this is happening, the DTWDEMO application is in the TWRC_XFERDONE message processing. If you are able to get a debug build to run, you will see this in ctltr031.cpp, around line 245 (you can put a breakpoint there). That is where I verified that all the strips were transferred, and the HP Utility app tries to start.

4) After this, more exceptions are thrown by the HP driver, similar to the initial one where an xml file cannot be located. The application ignores them, and the HP driver closes.

So I didn't get the hanging issue, but I certainly could see why an application will have issues with the driver if one or more of the utility apps don't start, or not installed properly.

[sean-neeley]

Thanks Paul. I'll be back in the office on Tuesday and that is when I can test again. I can let you know what HP software packages we have installed. I have seen that HP dialog appear before in the DTWAIN demo app, but I don't remember under what circumstances. It never appears in our own C# DTWAIN application, but like you said that could be related to the freezing.

I'm still struggling getting the DTWAIN dll compiled. Without compiling boost I get errors about missing boost related files. When I do compile boost, the DTWAIN project is looking for boost libraries with different names than what I have on disk. I can give more details on Tuesday.

[sean-neeley]

OK, Regarding the DTWAIN library build, I changed the compiler setting to /std:c++17 and have the boost folder in my include path. It seems to batch build OK, but I get these 2 link erors:

Regarding the HP scanner freezing... For the software we install the following packages from the HP website, in this order:

• HP ScanJet Flow 7000 S3 Full Feature Software and Driver
• HP ScanJet Enterprise Flow 7000 s3 ISIS Driver and Utilities
• KOFAX VRS 5.0
• HP ScanJet Flow 7000 s3 Basic Driver

We use KOFAX and the ISIS driver for an older build of our application that doesn't use DTWAIN, so that is why they are installed.

When using the DTWDEMO app, the HP Scanner Tools Utility does open the first time I scan, which is annoying For subsequent scans and runs of the application I do not see it. I found where the HP Scanner Tools "bin" folder is located and renamed it, just to see if that would stop the freeze up, however that did not help. When using the modified DTWDEMO app that I gave you at the beginning of this bug report, the app freezes on the "Processing Image(s)" when debugging in visual studio. However if I click on the Visual Studio icon in the taskbar, the action of switching focus away from the DTWDEMO window somehow makes it unfreeze.

[dynarithmic]

What options are you using to scan the image in DTWDEMO? Are you using the user interface? Is it buffered or native?

As to the linker error, what are the environment variable BOOST_LIBRARY_DIR_V143_64 and BOOST_LIBRARY_DIR_V143_32 set to? Are the libraries mentioned in the error found in those directories specified by the environment variables? The ones on my system are set to:

BOOST_LIBRARY_DIR_V143_32=c:\boost_1_81_0\lib32-msvc-14.3\
BOOST_LIBRARY_DIR_V143_64=c:\boost_1_81_0\lib64-msvc-14.3\

[sean-neeley]

For DTWDEMO, I'm using AcquiredBufferedEx and No UI. If you use the FullDemo.zip in my first post, it is a modified version of the demo that is hardcoded to use AcquiredBufferedEx and No UI. It is what I have been using to recreate the freezing problem.

I don't have any libraries anywhere in C:\boost_1_81_0, because I did not compile boost. I had trouble in the past getting it to build the static version of the boost libraries. Maybe I understood wrong, but I thought you said that if I use the /std:c++17 in my DTWAIN project, I would not need the boost libraries, only the header files. I'm trying to compile the DTWAIN DLL without the boost libs.

Thank you

[dynarithmic]

I think the compilation issue is due to Visual C++ not setting all of the flags when C++17 is selected. You should set the /Zc:__cplusplus option. You can do it by opening up the Properties for the project, then:

Configuration Properties -> C/C++ -> Command Line

and then in the Additional Options box at the bottom of the dialog, add:

/Zc:__cplusplus

Recompile. See if that solves the issue.

Also, there are still some components of boost that are required in library form, such as the dll component. However the filesystem component shouldn't be necessary once the C++17 compilation is successful.

[dynarithmic]

I just ran with the latest version of DTWAIN (5.3.0.1), 64-bit. Except for the exceptions being thrown, I had no issues with the C# project scanning with no UI, buffered mode (I tried a single page -- maybe you should try this also).

I did see some issues with the C# project, but these are probably minor:

1) If there is no paper in the feeder, and the source UI is not displayed, you will get a condition code error of 29, meaning there is no paper in the feeder. This might be an issue, since there is a C++ wrapper class that uses a timer, where the user can wait for a certain number of seconds before placing paper in the feeder.

The other issue is that the C# code doesn't test for this error, and hangs on the spot where it detects that no images have been captured. A call to DTWAIN_GetLastErrorString(DTWAIN_GetLastError)) should show that the paper has not been inserted into the feeder tray.

2) The HP scan utility pops up for me when all the strips have been transferred, so I'm still not so sure about the way this is supposed to work on the HP side.

3) I am still concerned about the exceptions being thrown by the driver because of some missing configuration files. I may have to see if there is any way to just log those exceptions and not have them interrupt the flow of the program.

But other than those issues, I didn't have a problem once the paper is placed in the feeder, the page is read (the paper basically flies out of this model of scanner -- not used to that, lol), and the image window displayed what was captured.

I used the latest driver version from HP for the 7000 S3. Here is the information, when logged by DTWAIN:

    Id=1
    Version Number=2.1
    Version Language=2
    Version Country=1
    Version Info=2.1
    ProtocolMajor=2
    ProtocolMinor=1
    SupportedGroups= DG_CONTROL, DG_IMAGE, DF_DS2
    Manufacturer=HP Inc.
    Product Family=HP
    Product Name=HP TWAIN USB

Maybe try the following:

Turn off the callback in the C# program. That is done by commenting out

        TwainAPI.DTwainCallback64 twainCallback = TwainCallbackProc;
        TwainAPI.DTWAIN_SetCallback64(twainCallback, 0);

Maybe the callback is causing the issue, not sure. I am not a C# expert, but I've always had some trouble with getting the callback mechanism to work properly, more probably because of my non-expert knowledge of C#.

[dynarithmic]

Also, have you tried to scan using another PC? Maybe there is something odd about your configuration.

[sean-neeley]

Yep, I have that same driver version.

TW_MEMREF is TW_IDENTITY:
Decoded TW_MEMREF:
{
    Id=1
    Version Number=2.1
    Version Language=2
    Version Country=1
    Version Info=2.1
    ProtocolMajor=2
    ProtocolMinor=1
    SupportedGroups= DG_CONTROL, DG_IMAGE, DF_DS2
    Manufacturer=HP Inc.
    Product Family=HP
    Product Name=HP TWAIN USB
}

When I test, I always use 2 or more sheets of paper. I haven't checked if that really matters or not.

I tried commenting out the callback and not using, because I had the same thought. It did not help unfortunately.

We also tried from another workstation and with another HP 7000 s3 scanner and it has the same issue. I can try from a third workstation, where I only install the HP basic driver.

Can you tell me how you built boost? I downloaded the latest version, unpacked it to C:\boost_1_81_0, then ran bootstrap.bat, followed by "./b2". I seem to have a different folder structure and library names from you. Thanks.

[dynarithmic]

For boost, I go to here and get the relevant binaries.

The installation automatically puts the headers and libraries in the correct folders. So for the Visual C++ family of compilers, there is no need to do a boostrap build, as the libraries are pre-built.

[dynarithmic]

Not sure how to get further with this, except to point out that the HP driver throws exceptions and will start the relevant applications.

If you can get boost to build, the way you debug the full demo is to

1) In the Solution Explorer, select the DTWAIN_DLL project, right click, and make it the Startup Project by select Set as Startup Project 2) Make sure the newly built DTWAIN DLL is the one your C# code is using. 3) In the Project properties: Configuration Properties -> Debugging and then Command, you enter the full path of the FullDemo.exe executable.

Then start debugging (F5/F10). What will happen is that FullDemo.exe will start, and then you can set breakpoints in the C++ code. You can start with ctlacquirebuffered.cpp, where the DTWAIN_AcquireFileBufferedEx starts. The file responsible for the buffered transfer from the device to DTWAIN is ctltr031.cpp, where you see the switch statement with the

case TWRC_XFERDONE:

around line 244 of that file. That code is executed when all of the strips have been transferred.

Note that starting the application from the DLL project is the only foolproof way of getting the C++ code to be debugged under C#. I tried to debug the code from the FullDemo C# project, but even selecting to debug the native code resulted in not being able to get to the C++ layer.

[dynarithmic]

To verify, here is a snapshot of the program after successfully scanning a page:

[sean-neeley]

OK, I was able to install boost using the exe and was able to get the 64bit dtwainu.dll to compile. I missed where you posted a link to the exe in an earlier reply, so I apologize for that. I was able to set a breakpoint in ctlacquirebuffered.cpp where the acquired buffered logic starts. When stepping through the code line by line from that point on, it doesn't freeze. However, if I test again and hit the breakpoint in the acquired buffered logic and hit the "play" button to continue execution of the program instead of stepping, it does freeze. I'm not sure how to tell where it is freezing. I hit the "pause" button in the debugger and it shows these threads:

Clicking between the application window and the visual studio window seems to make it unfreeze. Any advice for debugging and troubleshooting this sort of thing?

[dynarithmic]

I would look at the call stack to see what series of functions are being called.

The hpsxTwain.ds is the HP driver DLL that the TWAIN system is using to communicate with. Other than that, there isn't really anything directly related to DTWAIN in those threads that I can tell. If anything, possibly a call to the TWAINDSM.DLL (the 64-bit data source manager) is being hung on a call, and it is stuck in the HP driver code somewhere.

To verify this, the ctltwmgr.cpp file contains a function called CallDSMEntryProc. In there, there should be a lines of code like this:

    try
    {
        retcode = (*m_lpDSMEntry)( pOrigin, pDest, nDG, nDAT, nMSG, pData ); 
    }
    catch(...)

If the call stack points to that line of code (the retcode = ), then this means that the driver or the TWAIN system is hanging on a certain triplet call. To get the triplet that was sent to TWAIN, the values of nDG, nDAT, nMSG makes up the triplet. Those values correspond to what you will find in the TWAIN specification under the "Twain Triplets" umbrella. Recording those values will indicate what triplet was being sent.

[dynarithmic]

As to the screenshot, you could try and get the MS symbols by checking the "Microsoft Symbol Server". This should load the symbols for ntdll.dll, and then you can view the call stack to see what function is being called on the OS side.

Also, since you were successful in getting the dtwain64u.dll to compile, try to compile dtwain64ud.dll (the debug dll). You will have to change your C# code to use DTWAIN64UD.CS and rebuild. The debug DLL's are not optimized, so the source code will match up with the actual function being called.