An app, and dongle calls

Hi - hope this is the right forum. If not, please feel free to move it to wherever it should go.

I have an app that is protected via a dongle. I am not the developer of the software; I am the end user who has purchsed a license for the app. The app makes periodical calls to the dongle to check that it's there; one of these calls occurs when the app is instructed to shut down. This is evidenced by a flash that occors in the dongle. Occasionally - and seemingly randomly - there is no call to the dongle when instructed to shut down. When this occurs, the app hangs. Using TM/end process does not shut the app down completely. It shuts the GUI down, but there are still threads running. I am not the only one with this issue.

Before anyone starts to think that I am asking how to bypass the dongle - no. That is not what I seek here. What I was hoping to learn, is if there is some way to ensure that the aforementioned dongle call is made 100% of the time, as opposed to most of the time. As you can probably imagine, this is not an open source product, and being that none of you have the ability to look at any code, this understandably might be a longshot. But I have to try.

Maybe what I am looking for here, is something system-specific (which I would therefore have in common with all of the other users who have the same issue), that would cause an app - or the driver itself - to not communicate with it's protection device, be it the chipset, the MOBO itself, etc. Maybe something having to do with the way the BIOS are set? Maybe there is some 3rd party app that might be able to force communication between the app, driver, and dongle? I know that's a stretch, but...

I do have the latest dongle drivers, and the lateset version of the app itself. And this is not a new issue; it is 4.5 years old, and is across four versions of the sw.

This post might be a little light on info; if anyone thinks that they might be able to offer some assistance, I will be happy to publish more info if need be. I just figured it might be best to keep the initial post as straightforward and simple as possible.

Thanks in advance for any insight! :)

I'd try to figure out what my codepath was that bypassed the dongle call first. Or maybe I'd ask myself what the point was if the app is shutting down anyway. What's your plan if it's not there?

Not quite the same as you but may be of interest. I use a program that sometimes starts up correctly and sometimes doesn't. This seems quite random. I've had a lot of correspondance with the developers and now have been informed by them that the program is 'not multiple core compliant' - ie it will only work correctly all the time if the computer has only one core! I wonder if this situation re multi-core may be the problem with your program?

On a more general level, I wonder how many programs are going to be found that 'sometimes don't work' due to multi-core threading issues? I'm currently working on a re-write of a program which has just this sort of problem with multi-threading on multi-cores. Getting a multi-threaded program to consistently work correctly with a variable number of cores (from 1 to 32 and above) is definitely non-trivial!

Maybe I'm missing something, but assigning threads to cores is a function of the OS, not the programmer. I would think if there were threading issues, the number of cores should be irrelevant, unless the OS has bugs.

If the number of cores is 1, then even in a multi-threaded program there is only one thread executing at once. In a multi-core system there could be several threads of the same program executing con-currently on different cores - depending upon how the threads are assigned by the OS. Having multi-threads of the same program execute at the same time can show up subtle bugs in the application code that do not necessarily arise when multi-threads are processed using one core.

Quote:

---

Originally Posted by Jeff Hayat

What I was hoping to learn, is if there is some way to ensure that the aforementioned dongle call is made 100% of the time, as opposed to most of the time.

---

The way is using hardware USB sniffer. You should be able to take logs typical for normal shutdown as well as problem one. In case those differ somehow, you report the problem to SW vendor. Though I don't think end users should do things like this, and would suggest you to report anyway.

Thanks much for the responses.

Quote:

---

Originally Posted by GCDEF

I'd try to figure out what my codepath was that bypassed the dongle call first.

---

Ok, you kinda lost me there.... how would I figure out what the path is?

Quote:

---

Originally Posted by GCDEF

I'd try to figure out what my codepath was that bypassed the dongle call first. Or maybe I'd ask myself what the point was if the app is shutting down anyway.

---

The app isn't sutting down; that's why I am here.

Quote:

---

Originally Posted by 2kaud

Not quite the same as you but may be of interest. I use a program that sometimes starts up correctly and sometimes doesn't. This seems quite random. I've had a lot of correspondance with the developers and now have been informed by them that the program is 'not multiple core compliant' - ie it will only work correctly all the time if the computer has only one core! I wonder if this situation re multi-core may be the problem with your program?

---

Possibly. I have to check to see if the app is multiple core compliant, and if it is, whether or not the dongle driver is. Did the dev of your sw say the entire app may not function properly, or that the dongle may not function properly?

Quote:

---

Originally Posted by Igor Vartanov

The way is using hardware USB sniffer. You should be able to take logs typical for normal shutdown as well as problem one. In case those differ somehow, you report the problem to SW vendor. Though I don't think end users should do things like this, and would suggest you to report anyway.

---

Ok, just did a goodle search for USB sniffer. I found a few things; basically, it comes down to a visual picture of the traffic passing through USB subsystem. I have yet to try it, but what do I do with the info? Is this just for reporting to the dev and nothing else? I would really like to find a tool that will force the dongle calls that are supposed to be made, but I fear that no such thing exists.

Thanks again.

When it's hung, break into the code using the debugger and see where you are in the code and how it got there.

Quote:

---

Originally Posted by Jeff Hayat

I would really like to find a tool that will force the dongle calls that are supposed to be made, but I fear that no such thing exists.

---

I'm not aware of what kind of data interchange is done on USB channel in your SW. So I suppose some special/custom USB driver is in use, developed by the SW vendor. If this is the case, the driver is the entity that performs dongle calls, and I hardly can imagine how you could "force" the driver to do what it does not.

Data interchange is typically done like this: app calls driver API dll, the API dll calls driver, driver issues low level commands to HW (dongle), HW responds back to driver, driver puts received response data to a buffer provided by either API dll or user app. As you can see, there are many entities participating in this exchange. And most probably problem may be in app, API dll or USB driver. Which all are provided by the SW vendor. It is very unlikely that some OS components cause some effects that prevent this chain of components from working correct.

And even if this effect really exists in your particular case, this is SW vendor who is responsible to fix it or provide a solution how to circumvent.

Quote:

---

Originally Posted by GCDEF

When it's hung, break into the code using the debugger and see where you are in the code and how it got there.

---

Eh, dubugger? What debugger?

Thank you for your thoughts Igor.

I'm not aware of what kind of data interchange is done on USB channel in your SW. So I suppose some special/custom USB driver is in use, developed by the SW vendor. If this is the case, the driver is the entity that performs dongle calls, and I hardly can imagine how you could "force" the driver to do what it does not.

Yes, the driver was dev'd by the sw vendor. And yeah - "forcing" the driver to do what it does not is a longshot I know.....

It is very unlikely that some OS components cause some effects that prevent this chain of components from working correct.

What about hw components....MOBO components, the chipset....?

And even if this effect really exists in your particular case, this is SW vendor who is responsible to fix it or provide a solution how to circumvent.

Agreed - but this problem has been here across four different versions (not updates), and over four years. If they have not yet fixed it, I fear that they simply will not.

Thanks again.

Quote:

---

Originally Posted by Jeff Hayat

Eh, dubugger? What debugger?

---

Seriously? You need to learn how to use it. MSDN can explain it better than I can.

Quote:

---

Originally Posted by Jeff Hayat

Yes, the driver was dev'd by the sw vendor. And yeah - "forcing" the driver to do what it does not is a longshot I know.....

---

As I said, the problem may be in app, or in driver API, or in driver itself. Or in order of calls. Or threading deadlock. Or timings. Or driver unwanted unload. Or something else. Even to investigate what's going on you need a source code, not just a bare belief or desire. ;)

Quote:

---

What about hw components....MOBO components, the chipset....?

---

And? What's your idea? Are you going to test through all motherboards from your nearest computer shop? The shot is going to be very long. And expensive for sure. ;)

Quote:

---

Agreed - but this problem has been here across four different versions (not updates), and over four years. If they have not yet fixed it, I fear that they simply will not.

---

If so, sorry, but you're in trouble. A problem prior to be fixed must be understood. Your description sounds just like "something doesn't work sometimes." No source code, no logs, no other diagnostics, no clear procedure how to reproduce. This is not the way how engineer problems get fixed. Sorry, I really hate to disappoint people, but under the circumstances the case seems hopeless.

Hi Igor, and thanks again for your thoughts. I understand exactly what you are saying, but when it's like this:

Attachment 30923

...it's just something that I feel should be fixed, even tho it may not be reproducible.

Cheers.

Quote:

---

Originally Posted by Jeff Hayat

Hi Igor, and thanks again for your thoughts. I understand exactly what you are saying, but when it's like this:

Attachment 30923

...it's just something that I feel should be fixed, even tho it may not be reproducible.

---

So in the end, what are you looking for in the Visual C++ forum? I don't see a C++ question, just some musings on a piece of supposed buggy hardware.

If anything, GCDEF suggested the closest thing that has anything to do with the topic of this forum, and that is to use the debugger to debug whatever you're having trouble with.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Paul McKenzie

So in the end, what are you looking for in the Visual C++ forum? I don't see a C++ question, just some musings on a piece of supposed buggy hardware.

If anything, GCDEF suggested the closest thing that has anything to do with the topic of this forum, and that is to use the debugger to debug whatever you're having trouble with.

Regards,

Paul McKenzie

---

At this point, we don't even know if the program is getting to the point where the dongle is called. That's why you need the debugger, to show you where in the code the program is hanging. Without it, you really have nothing to go on. The problem may have nothing at all to do with the dongle API. First thing to do is find where it's hanging, how it got there, and what's wrong that's causing it to hang. The debugger will show you all that.

Quote:

---

Originally Posted by Paul McKenzie

So in the end, what are you looking for in the Visual C++ forum? I don't see a C++ question, just some musings on a piece of supposed buggy hardware.

---

I know almost nothing about programming and code. I tried to do the right thing by originally saying:

Quote:

---

hope this is the right forum. If not, please feel free to move it to wherever it should go.

---

Instead of simply telling me this doesn't belong here, why not offer a suggestion as to where it should go?

As for the debugger sw, is there a recommendation of what I should look into? Bearing in mind my level of skill (or lack thereof).

Thanks again.

Quote:

---

Originally Posted by Jeff Hayat

Instead of simply telling me this doesn't belong here, why not offer a suggestion as to where it should go?

---

Does a forum named Visual C++ Programming sound like a forum to ask about buggy or supposedly buggy hardware dongles? Why didn't you choose the "General Chit Chat" forum?

Quote:

---

As for the debugger sw, is there a recommendation of what I should look into? Bearing in mind my level of skill (or lack thereof).

---

Microsoft Visual C++, the topic of this forum, comes with a debugger. That is what GCDEF is referring to.

You start your application under the debugger -- when it hangs, a "Break All" will show you the function that it is currently executing, as well as the list of functions that got you there (if you look at the call stack). That is about all you can do, and even that may not be feasible if the software has anti-debugger protection (where running under a debugger will cause the software to crash on purpose). Anything else requires the programmer(s) at the manufacturer's site to debug and fix issues.

Regards,

Paul McKenzie

I just read the OP again. You're the end user? Do you even have the source code? Have you contacted the company that made the app?