I've been developing our company's credential provider for windows 10 for almost a year now.
Now, I encountered a problem. I don't usually ask questions on forums, blogs, because in most cases I find the solution, but this time I've been struggling with an issue for a month now and I found the root of the problem.
Brief description of the problem itself: The credential provider uses a combobox, which worked before without a problem. Now, I rewrote the whole code to manage a big update, but a strange bug got into the system. The bug only occurs at a specific scenario. I'm developing and testing the code on my personal laptop.
The scenario:
1) The laptop is plugged in to my monitor / power, etc.
2) I make it go sleep.
3) I unplug all cables (including power).
4) I wake it up from sleep.
Than, the combobox doesn't show a default selected item, it's empty. When I drop it down, it shows all the necessary items. Than the credprov crashes and restarts, than everything is fine.
I know, that in similar "strange" scenarios, in most of the cases, a memory leak or something related causes the problem. When I check the event viewer it shows me c0000005, which is access violation. I started to debug where the violation is. Than I found out that the program refers the combobox item list array (actually vector in my case) at a very very high index (out of range could be the reason for the violation). The actual index is obviously stored in the "selectedComboItemIndex" variable (DWORD).
I was curious when did it change to this strange number, than I found an unexpected behavior.
The SetComboBoxSelectedValue method randomly gets called once (when the bug happens) with an insanely high index value. I don't even call this method in my code, so I have no idea, why does it get called. The call happens even when I don't drop down the combobox.
I give it a chance that it could be a bug in the credprov itself. What do you think? Have you seen this problem before?
Thank you in advance!
I solved the problem by stopping to use "SetSelected" and "SetDeselected" methods. Furthermore, I filtered the "SetComboBoxSelectedValue" input parameters to accept valid numbers only. When the index parameter is invalid, I recall the same method with the index parameter replaced to the first item (0).
Related
I'm not sure if this is the good website for ladder logic programming questions but I will it a try.
I'm using a Click PLC C0-01 DR-D by Koyo (Desc page: http://www.automationdirect.com/adc/Overview/Catalog/Software_Products/Programmable_Controller_Software/CLICK_PLC_Programming_Software) with it's free software. I'm trying to make a program in Ladder Logic to executes multiples operations by the PLC. To keep track of the current operation, I use an integer value I'm incrementing as the current operation ID. However, I'm not able to reset this value to 0.
First I tried with the COPY but there's a radio button to ignore zeros. This radio button is checked and disabled (can't change it). . The documentation of the software says "Option: This Option is available when the Source is a Data Memory Register Address and the Destination is a TXT Address." But since I just want an ID and I need to compare this ID with = everywhere in my program and increment it, I don't want to put a string.
Then, I can use math to assign a formula to a variable. I tried put zero and it's working half the time. Note that the "One shot" checkbox isn't selected even if it may to be acting like so.
About this option, the documentation says "One Shot: Select One Shot to solve the formula only once after each OFF-to-ON transition of the enabling rung."
However, to be able to set the value to 0 again, I need to restart the PLC. When I first execute the program everything is fine because the value is already 0. When I restart it, the value didn't reset so it's still 7 and it skips all my operations. Then it resets to 0 (it's doing so at the end) and when I restart the PLC, I'm able to run it normally for one time.
Here an example of the current passing but the value not set:
Is it a bug from the PLC ? Is there a workaround ?
In short, I'm looking for a reliable way to set a value to 0.
Thanks in advance for the answers. Sorry If I violated 40 rules, I'm new and happy to join this community.
I though I resolved my problem but I just pushed it further. Thanks to Garry Shortt with his youtube channel dedicated to PLC programming for helping me out with my problem.
His explanation to the problem is "Changed the math to a copy command and placed it in the main program where you had it before. The program seems to work well.
The only thing that I can think of is when you use subroutines, and they are not being scanned. The items within the routine is the same unless you them changed in another part of your program."
Hope it will be helpful for someone someday.
All of a sudden, I'm seeing floods of first chance exceptions in the VS.NET Output window.
There are 3 of us working on the project. We've all updated our code to the latest in SVN and I'm the only one seeing all the exceptions, so the issue is not our app, but I suspect, some setting that I accidentally triggered in VS.NET.
If I right click the Output window, "Exception Messages" is checked. It always has been and is for my co-workers, so that's not the issue.
I cannot see any options in Tools/Options/Debugging that could be responsible. I suspect I probably just accidentally hit some accelerator key combo that did it. These appear to be perfectly normal first chance exceptions (like setting a property in a dynamic object for the first time causing a RuntimeBindingException). The app seems to operate just fine. But the flood of messages is annoying and makes debug output hard to follow.
By far the most common exception is an ArgumentException with the message, "A property with the name 'UriTemplateMatchResults' already exists."
We use WCF very heavily (but no REST) and have a number of WCF services that our app communicates with, so I'm assuming that's just standard WCF stuff because the calls are all working fine.
Can anyone think of anything I might have done?
I discovered the source of the problem. As I suspected, it was something I had accidentally done, but I'm not sure when or exactly how. Hopefully this solution will help others.
The solution was Tools/Options/Debugging in the General section, I had somehow unchecked Enable Just My Code. I'm not sure how I unchecked it. That fixed the problem.
I am in the beginning phase of a new VB.net Windows Forms project in VS 2013 that is connected to a TFS 2013 application tier. I have updated the VS client using Microsoft Update to include all hotfixes available for it at the current time.
There are 2 problems that I'm having:
Breakpoints are ignored (eventually)
F10 (Step Over) & F11 (Step Into) don't work properly (They work maybe once or twice, then totally step out of all running methods)
The problem morphs as time goes on, but here is essentially what happens (NOTE: I have a breakpoint already set in a method that is called on Form Load, so the expected behavior is that the breakpoint is hit before the interface is usable. Also, there are about a dozen lines after the breakpoint in the method)
F5 to start the project in debugging mode
The form loads and does not stop at the breakpoint
Make a change that calls the method
The application stops at the proper point
Hit F10 once, it goes to the next line
Hit F10 again, it completely steps out of all running methods, bringing me back to the interface (What I expect here is for it to go to the next line)
Repeat steps 3-6 consistently until it just continues and does not stop at the breakpoint again, nor does it allow me to Step-Through or Step-Into any methods
Some additional information:
I have another, larger in size VB.Net application that has never experienced issues with debugging
When I set up VS2013, I chose General Development, and the only change I made from the default settings was to change the color scheme to the dark scheme.
In my research, the only articles I have really found pertaining to 2013 that were even remotely relevant all pointed to this article: VS/2013 Debugger Not Working (MFC/C++/CLI w/ previous version of MFC library)
This article sounds like it has similar behavior, but it's pertaining to projects that contain both C# and C++ code, which mine does not.
Does anyone have any insight as to what could be causing this, and what I can do to work around it? I didn't have these issues with VS2012 and I think I will probably use that for this project until I can get the issue resolved.
Ok, I found the problem.
It stemmed from the fact that each of the lines I was trying to step over or into had an InvalidCastException (I was trying to add an Integer and 2 Strings together, and stick them in another string. When the strings were blank, it was trying to convert them to Double). These errors were NOT causing the application to break, it was silently ignoring them and putting them in the Output window (Which I wasn't paying attention to).
The irony is that I knew there were going to be errors on those lines, and I was trying to figure out what they were so I could do the conversions properly.
The breakpoints failed when I had one of the lines set to break that was generating the error, and the Step Over functions would completely skip past them.
Once I fixed the InvalidCastExceptions, debugging started working properly again.
I'm having a strange issue with my application for Mac OS X. I have a process that runs in a secondary thread. The process repeats a certain action a user-specified number of times in a for loop.
With each iteration of the for loop, there is a string that is initialized with the contents of a strings file. If the content of the strings file equals "YES" then the loop breaks (the file is set to "NO" by default). When the user wants to stop the loop, they hit the "Stop" button which sets the contents of the file to "YES".
This actually works great when I run the application in Xcode and when I export the application as a .app. The problem occurs when I actually turn the application into a pkg and install it. The stop function no longer operates correctly. I'm pretty stumped as to what the issue is. I'm initializing all my references to my file using [NSBundle mainBundle] so I should be referencing the file in my application bundle.
EDIT: I actually decided to switch to checking an atomic BOOL value within the loop that I change when the stop button is pressed. This seems to be a simpler solution for me.
Regular users do not have permission to modify applications installed in the /Application folder for very good security reasons. Also, signed apps (ie, any app sold through the App Store) cannot be modified without invalidating your signed code.
Never, ever, ever rely on the application bundle being modifiable. It's never supposed to be. Always use standard user data folders like "~/Library/Application Support/" or "~/Library/Caches/" for app-related, non-document files.
As to your general approach, repeatedly polling a file - especially in a tight loop - is a lot of disk activity. "Laptop Killah" would be a good name for the app. :-) You should consider changing this approach altogether. If you provide more detail in another question (what you're doing and why) and ask for suggestions, I'm almost positive there'll be a number of better ways that don't chew through your users' battery charge like crack-addled rats in a grocery store.
Also, I'm guessing you never check to see if your file is written successfully. The standard -writeToURL/File:... methods return a BOOL to signal success or failure as well as set an NSError (if you pass a pointer to one) with further details. Get into the habit of not ignoring this. In this case, you might've found your own answer because you'd have known just where your code is breaking. From there, it wouldn't have been a huge leap to figure out why.
Say you have the following code block:
if (Light.On) {
// do something...
} else if (Light.Off) {
// do something else...
} else {
// this state should never be reached
}
Now assume that the applications logic dictates that in this part of the code, the last state should never be reached, but it is not something that can be determined at compile time. And maybe there ARE other states (e.g. Light.Broken) which could be set by other parts of the application, but which are not used here.
What code do you add in the last else block?
Add no code, because it should not be reached anyway.
Add some logging functionality, so that you as a developer know that some illegal state has been reached.
Throw an exception, because the state must not be reached and if it is reached anyway, something else must be wrong.
The first option doesn't seem reasonable to me, hoping something goes right seems hardly the right choice. Option two has the advantage that your app doesn't crash right away, so if this happens in a rare occasion which was not caught in testing, the customer can continu using the application and the developer is notified of the problem. Option three causes the app to crash, which obviously is not something you want your customers to experience, but it does make it very clear that something is wrong.
What is the best way to handle such a situation?
EDIT, based on comments:
Some additional consideration to steer the discussion:
The contract of the method that contains the above code does not allow any other values to be set at that moment then On and Off.
Assume that the code is in a not-so-critical part of the application.
In development - fail hard and fail fast. Throw some kind of runtime exception, or just Assert(false).
In a release - shutdown gracefully. Your app is in an unusable state, and you cant realy on anything that you normally would, such as class invariants etc. Give the user a chance to save thir work, for example, try and log an error that could be sent back to the dev team and then shutdown.
EDIT: Based on comments added.
If the contract of the function states that the light shouold be on or off at function entry then any other state is an error. The function should fail, according to the principles outlined in my original answer.
Regarding the 'non-critical' aspaect - if a function precondition is not being met that means that your application is broken. Regardless of wether the error is detected in a non-critical piece of code, that does not imply that the problem itself is non-critical - you have no way of knowing that the bug that creates the invalid state doesnt also affect critical areas of code.
Well ... It depends. Having a third case for a boolean test would make me want to cry. It's just noise, adding confusion and telling me the developer was at least as confused as it makes me feel.
For a non-boolean, I guess you could do whatever ... If the ifs capture the states that are relevant to the code in question, there's no harm in just ignoring other cases. If there's a good chance that further cases will be needed in the future, a comment might be enough to indicate that for clarity.
As already said, in development phase you should make it visible as soon as possible. In release phase, it depends on how critical it is to reach this invalid state.
The least is to issue a log for debugging purpose.
Then you can try to recover from this invalid state either by going back to a previous valid state or by going to a new valid state.
Finally if nothing safe can be done, you can terminate the execution (with an alert to the user and a log to the maintainer).
3rd option is the correct as if for that part any other state is not valid so it should throw and exception saying invalid state.
Don't do anything. If all you care about is whether the light is on or not:
if (Light.On) {
// do some work
} else {
// too darned dark to work
}
Otherwise you should enumerate all your states.
If the other states are not allowed, you should error. If they're allowed but irrelevant, just ignore them. With properly designed code, there is no problem.
You're main problem here lies in a design that can have Light.On and Light.Off set at the same time. You should be using a state Light.State which is set to one of {on, flickering, off, broken, unplugged, exploded, emitting_dangerous_gamma_rays} and so on.
Throw an exception.
As you said, the third case should never occur. If it does happens, then something went wrong, and you don't know what else can be going wrong.
You also don't want calling code to think that code is working normally, when it is actually failing.
Additionally it makes it a lot easier to spot the issue Before it is released.
In the development version, just throw an exception.
In the release version:
Throw an exception
Save the user's work in some temporary file if possible
Save a crashdump and (using a small helper application) offer the user the option of sending it to you so you can identify and fix the problem