Any suggestion to detect flaws in VB6 components running under IIS. IIS becomes unstable and after some time enter in a state of hang. The problems occur in the most part only in the production environment. We have many modules running. Probably there are components with bugs and need to identify them.
Thanks in advance.
One thing to watch out for is multi-threading issues. VB6 components often don't play well when accessed by multiple threads.
If the client code is an ASP.NET application consider putting synchlocks around the calls to ensure that they are called sequentially.
Another sure-fire way to fubar IIS is to display a message box or initiate some other sort of user interaction. Get those MsgBox calls outa there.
Other than that... good logging helps. VB6 is pretty opaque when errors arise.
Use Debugging Tools for Windows to analyze a dump of IIS. Tess' blog is one of the best resources to learn to use WinDbg. Although she focuses on .NET debugging, most of the material is applicable to any Win32 process.
Related
We have a classic ASP page that makes a request to another page on the same site to get data.
When debugging is turned on we get deadlock because the web server will only respond to one request at a time.
What is the best way to get around this limitation while still allowing us to debug it while developing?
Less than ideal options:
Move the page to another site.
Allow iis to use multiple processes.
Any other options?
Ah, the joys of Stackoverflow, where instead of getting answers you're criticized for using Classic ASP, which is a currently supported tool even though it's been around for 100 years. :-)
I ran into a similar problem a while back while trying to create a simple script that would mimic the behavior of a script located on another server. I wanted to do some debugging without invoking the real script, so I thought I'd make a brain-dead replacement for it on my own server and invoke it the same way.
I ended up giving up and using the real script for my debugging. But today I found this KB article for you that might help: http://support.microsoft.com/kb/316451. I'm not sure but I think that's the solution. Or something like it.
Is it possible to disable / bypass Unity3D main thread check when accessing methods and fields from classes in UnityEngine and UnityEditor from other threads?
If so, what are the ways to achieve this?
Does anyone know how Unity Team have implemented this check?
(I know of, and am currently using other techniques that allow me to successfully resolve any multi-threading problems, but this question is of rather academic type :)
Please respond only with possible solutions or informations why this cannot be done.
If Unity doesn't allow you to do something on the main thread respectively not on the main thread, assume there is at least one good reason for that.
Trying to circumvent it will almost inevitably result in problems, possibly hard to debug ones because Unity is trying to protect you from doing both outright illegal things that will corrupt or crash the app (ie accessing OpenGL context from a different thread) or things that are most likely going to lead to potential issues like race conditions, deadlocks, etc.
So even if there were a way to bypass said checks, without access to the code and profound understanding of multithreaded programming in the context of that code it would be highly counterproductive, self-defeating and setting yourself up for failures and hard to debug issues if you did actually manage to bypass said checks.
Every framework comes with a set of rules to work in. If Unity is saying "this method must be called on the main thread" you just follow those rules. Especially because you don't have access to the engine source code and could prove otherwise that in this specific set of circumstances it wouldn't be a problem. And if you had the source code, you could disable the check for those specific circumstances. Still, if the framework developer(s) insist that this wouldn't be a good idea you'll better listen to them because they surely know their framework far better than anyone else.
Okay, here's a complicated one I've been breaking my head over all week.
I'm creating a self service system, which allows people to identify themselves by barcode or by smartcard, and then perform an arbitrary action. I run a Tomcat application container locally on each machine to serve up the pages and connect to external resources that are required. It also allows me to serve webpages which I then can use to display content on the screen.
I chose HTML as a display technology because it gives a lot of freedom as to how things could look. The program also involves a lot of Javascript to interact with the customer and hardware (through a RESTful API). I picked Javascript because it's a natural complement to HTML and is supported by all modern browsers.
Currently this system is being tested at a number of sites, and everything seems to work okay. I'm running it in Chrome's kiosk mode. Which serves me well, but there are a number of downsides. Here is where the problems start. ;-)
First of all I am petrified that Chrome's auto-update will eventually break my Javascript code. Secondly, I run a small Chrome plugin to read smartcard numbers, and every time the workstation is shutdown incorrectly Chrome's user profile becomes corrupted and the extension needs to be set up again. I could easily fix the first issue by turning off auto-update but it complicates my installation procedure.
Actually, having to install any browser complicates my installation procedure.
I did consider using internet explorer because it's basically everywhere, but with the three dominant versions out there I'm not sure if it's a good approach. My Javascript is quite complex and making it work on older versions will be a pain. Not even mentioning having to write an ActiveX component for my smartcards.
This is why I set out to make a small browser wrapper that runs in full screen, and can read smartcard numbers. This also has downsides. I use Qt: Qt's QtWebkit weighs a hefty 10MB, and it adds another number of dependencies to my application.
It really feels like I have to pick from three options that all have downsides. It really is something I should have investigated before I wrote the entire program. I guess it is a lesson learnt well.
On to the questions:
Is there a pain free way out of this situation? (probably not)
Is there a browser I can depend on without adding tens of megabytes to my project?
Is there another alternative you could suggest?
If you do not see another way out, which option would you pick?
I'd like to sandbox a native code and use hooking of WinAPI and system functions to block or allow this program to perform some operations like reading/writing files, modify Windows registry, using an Internet connection. Is it a good and secure way to do so? How difficult would it be for that program to bypass such a security layer?
I've checked your questions and they all are related to the task that seems to be invalid from the very beginning, and here's why: you are trying to secure one application and you are ready to reinvent the wheel for this. There exist several approaches (and many ready-made solutions) to solve your problem. So instead of coding you need to look at existing solutions.
The approaches are:
use Windows permissions to restrict
access of your application to
resources
take take VMWare or Parallels or
other virtualization platform and
run your program there
take sandboxing SDK (such as
BoxedApp) and "wrap" your
application.
+1 to Hans, however if you are really into it then I can recommend Easyhook. I have personally used it successfully in Win XP, Vista and 7. I don't know how bypassable it is but other alternatives do exist - madSHI hooks, and, if you want to go the official way, try Detours from Microsoft.
Antivirus apps try to solve nearly the same problem, without much success.
1. You'd never know how even most common operations can be used.
2. There're syscalls, so the program doesn't have to use winapi at all.
In Windows Vista, I am unable to drag/drop files onto my application's window because it is running as a high integrity level process. I need to run it as high, but I also need to be able to accept dropped files from low/medium integrity level processes like Windows Explorer. I believe it is UIPI that is blocking the drag/drop operation. I know that I can use the ChangeWindowMessageFilter function to allow certain Windows messages to bypass UIPI, but I'm not sure which messages to add to allow the drag/drop operation. Is ChangeWindowMessageFilter the right approach to permit this, or is there a better way? Thanks!
Considering the title of this blog entry:
"Why you shouldn’t touch ChangeWindowMessageFilter with a 10-ft pole…",
I guess it is not the best approach ;)
Now, this might seem like a great approach at first - after all, you’ll only use ChangeWindowMessageFilter when you’re sure you can completely validate a received message even if it is from an untrusted source, such that there’s no way something could go wrong, right?
Well, the problem is that even if you do this, you are often opening your program up to attack unintentionally.
Consider for a moment how custom window messages are typically used; virtually all the common controls in existence have “dangerous” messages in the custom class message range (e.g. WM_USER and friends).
Additionally, many programs and third party libraries confuse WM_USER and WM_APP, such that you may have programs communicating cross process via both WM_USER and WM_APP, via “dangerous” messages that are used to make sensitive decisions or include pointer parameters.
In the comments of this blog entry, an alternative approach was discussed, but with pretty much the same conclusion:
I would use RegisterWindowMessage and then allow that via ChangeWindowMessageFilter.
However, be aware that you cannot design a cross-process window message interface that passes pointers or other untrusted values or you are creating a security hole.
For this reason, I would tend to avoid using window at all messages for most cross-process IPC (if possible), as it is typically very difficult to do non-trivial things in a secure fashion using them.
Note: this entry "So, who wants to design a feature today?" illustrates the same problem, and points to the insightful articles of Raymond Chen:
Why aren't console windows themed on Windows XP?
Windows Vista has more extended options on the context menu
which both detail the issue.
This ServerFault question "Why can’t I drag/drop a file for editing in notepad in Windows Server 2008?" also includes some answers, but no quick-win.
See also this article on IE