Strange problems with WaitForSingleObject Windows function
-
I am having a really strange problem with a component designed to watch for the printer events: First of all, the component has been working like a charm for years in all of the computers in which I have tested and with several operating systems (Windows XP, Vista, 7 and 8.1), in 32 and 64 bits, and running as normal user and local admin as well. However, in the computers of my last customer (Windows 7 64 bits) it only works when running as local admin which is, of course, unacceptable. Before bothering the admins of my customer I would like to know if someone of you has any ideas about the issue, because I have to confess I am completely puzzled. Basically, the compoment starts a thread in which it invokes FindFirstPrinterChangeNotification, which returns a valid handle. Then it invokes WaitForSingleObject for that handle and here is where things get strange: in every other computer, as I said before, it receives and processes the signals perfectly, but in my customer's ones, unless run under local admin, it just stays waiting and receiving no signals no matter what the printer is doing. I mean it does nothing, not even errors. It just waits but the signal does never arrive. I have been reading through the MSDN documentation but I cannot find any plausible explanation: the printer is a local printer which prints to a file and, yes, WaitForSingleObject requires SYNCHRONIZE access right, which I think shouldn't be a big deal. I have not pasted code here because, as I said, it works like a charm in every other computer, so it must be a security configuration issue. Any ideas? Thank you very much.
-
I am having a really strange problem with a component designed to watch for the printer events: First of all, the component has been working like a charm for years in all of the computers in which I have tested and with several operating systems (Windows XP, Vista, 7 and 8.1), in 32 and 64 bits, and running as normal user and local admin as well. However, in the computers of my last customer (Windows 7 64 bits) it only works when running as local admin which is, of course, unacceptable. Before bothering the admins of my customer I would like to know if someone of you has any ideas about the issue, because I have to confess I am completely puzzled. Basically, the compoment starts a thread in which it invokes FindFirstPrinterChangeNotification, which returns a valid handle. Then it invokes WaitForSingleObject for that handle and here is where things get strange: in every other computer, as I said before, it receives and processes the signals perfectly, but in my customer's ones, unless run under local admin, it just stays waiting and receiving no signals no matter what the printer is doing. I mean it does nothing, not even errors. It just waits but the signal does never arrive. I have been reading through the MSDN documentation but I cannot find any plausible explanation: the printer is a local printer which prints to a file and, yes, WaitForSingleObject requires SYNCHRONIZE access right, which I think shouldn't be a big deal. I have not pasted code here because, as I said, it works like a charm in every other computer, so it must be a security configuration issue. Any ideas? Thank you very much.
-
I forgot to say this in the original post, sorry for that, but the printer driver was also written by myself, that is why I am so puzzled. Anyways, testing with other printers makes no difference: it works fine everywhere I test it but in the customer's computers it does the same... nothing, not even errors... Thanks for the tip anyway, Eddy.
-
I forgot to say this in the original post, sorry for that, but the printer driver was also written by myself, that is why I am so puzzled. Anyways, testing with other printers makes no difference: it works fine everywhere I test it but in the customer's computers it does the same... nothing, not even errors... Thanks for the tip anyway, Eddy.
Their IT folks probably twiddled with some group policy settings or something. I don't know how to even begin backtracking from the behavior to which setting it might be.. maybe have a chat with the IT department and see if you can track it down from what settings they change?
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
Their IT folks probably twiddled with some group policy settings or something. I don't know how to even begin backtracking from the behavior to which setting it might be.. maybe have a chat with the IT department and see if you can track it down from what settings they change?
We can program with only 1's, but if all you've got are zeros, you've got nothing.