I constantly run into problems where a program runs fine on my system (installed and in development environments) but fails on a users system.
The best solution I can conceive is to debug the program on the users computer, but that's not practical since it would require me to install VS on their system and move the source code over (and doing so would compromise the integrity of the test environment anyway since it may cause the bug to vanish).
I want to remote debug but what I'm reading from the MSDN says to me "Nope, you can't do that unless both systems are on the same network (all. my. rage.)" :
Network configuration
The remote computer and the Visual Studio computer must be connected over a network, workgroup, or homegroup, or else connected directly through an Ethernet cable. Debugging over the Internet is not supported.
Is there another option I can use to connect to the process that is running on another system outside my network?
A partial solution (for the case that throws an exception).
Instead of trying to reach client app over the Internet, generate crash dump and debug it locally, in a comfort of your home :). Please see MSDN for details.
You can use a tunneling application (like hamachi). This will allow you to connect the other party like you're on the same network. Then you can use the remote debugging option. But even in local network remote debugging works slow and sometimes fail with code-optimized builds. Before using the "remote debugger" (by assuming there is any exceptions) I suggest to log all exceptions to a log file then watch the system. It will be helpful to put .pdb files to the remote system to see the relations between code.
Related
I am currently attempting to deploy an app to a Windows 10 tablet running the Creator's Update, over my local network. When I select remote machine and enter my debug settings, I can discover the tablet on my network, and get its address and Authentication mode automatically.
However, when I try to deploy, I get this error:
DEP6957 : Failed to connect to device using Universal Authentication. Please verify the correct remote authentication mode is specified in the project debug settings. 0x8007274C: The network event being waited on triggered an error.
As far as I can tell from the documentation that I've read, this process should be more or less plug and play since the Creator's Update, can anyone explain what I might be doing wrong, or what might be going wrong?
Listed here are my debug settings currently in use.
Update: Since its not the solution I was looking for, I'm not adding it as an answer, but if anyone comes across this looking for a fix and no one has suggested one, the way I ended up working through this is just downloading the remote debugger to the tablet and running the old method for C# apps. I never did find out why the UWP method didn't work.
I have an application that creates a HTTP server on a random port (50000-59000) on "localhost". It tries to connect to this port afterwards to determine if everything was setup correctly and is ready to use.
This seems to work on most machines very well. Its written in C#.NET 4.0 for Windows XP and higher.
Now I have the problem that on one server at one customer the creation of the server seems to work but it can't connect to it. Sadly we didn't any information as the exception details were not outputted from this software as it has happened.
It works if the file is on local disk. If they start it from a specific Windows network share it stops working. I think that the have a special setting which causes this issue. But I don't know that could be reason.
My Question:
Do you know settings, an system administrator could make, that prevents a software, running as normal user, to connect to a listening port, that the program has opened just a moment ago? May be group policy settings in the active directory?
I've written a test program to try this again at our customer.
Background
I have written a utility that watches for files in a certain directory, and then copies them to defined target locations on remote machines. There is also a feature that allows stopping defined services in order to allow copying to the target.
In our work environment, these remote machines are typically VMs (we use VMWare Workstation) and the machines are part of a VM sub-domain, and are configured to use NAT networking (share the host machine's IP address). So when I say "remote" it's really referring to a VM running on the host.
Problem
For my utility, I'm trying to copy files using a UNC path to the target directory, and using the machine name get a list of services using the ServiceController.GetServices(string machineName) method.
So if you had a VM named server-1, you might be trying to copy a file to \\server-1\c$\destinationfolder. Most of the time this works, but sometimes I see an excetion because the target directory can't be found. When this happens, we also see an error when trying to get services on the remote machine - "The RPC server is unavailable."
When the VM is restarted, everything works fine... for a while.
I'm having a hard time trying to nail down the issue, because it's sporadic and doesn't affect most people. I'm wondering if it's an IP issue, where VMWare changes the IP and it's stale in the host's cache? (If I sound like I don't really know what I'm talking about here, it's only because I don't... my networking knowledge is fairly basic). When I look up issues with the 'RPC server is unavailable' error, I see a lot of answers regarding firewalls, which I don't believe is the case here. We don't run anything like McAfee internally and since it works most of the time, it doesn't seem like the cause.
Actual Questions
Anyone have any thoughts as to what might cause this problem? As a follow-up, if it is a stale IP issue, how could I recreate the issue for debugging purposes, so I can try to come up with a good way to resolve it going forward?
When I attach to a process, wfica32.exe I get a message saying "no source code available". This application launches through Citrix.
Of course I have no issues attaching to this application and viewing its source code when it runs locally. Unfortunetly, the error I experience only occurs when running through Citrix. I suspect a race condition.
I added the *.pdb files to the server. Is it possible to attach to a process and see source code in a Citrix session?
You can't expect to be able to debug an application that runs on a remote computer you are connected with, attaching debugger to Citrix Client process (wfica32.exe you mentioned). What you need to do is to setup remote debugging (which might be just impossible in some cases). You can find more information on msdn: http://msdn.microsoft.com/en-us/library/bt727f1t.aspx
The PDB files will give you the symbols, but you'll need the source files on the server as well.
I have problematic deployment of my application on some client computer.
I really need to see what is going with my application in the run time and my logging is not sufficient.
The computer is on separate network that I don't have any connection there from my office.
Is there some tool that can record the execution of my application?
At least inputs outputs of functions?
Your hurdle here is that the target machine is on a remote disconnected network from your own, which makes use of the Visual Studio Remote Debugger tool useless (unless you're able to open firewall ports to the target machine, or establish some kind of VPN).
Try The Remote Debugger, install a VPN client on your machine and theirs (Hamachi is a good example), then the remote debugger should function (docs on MSDN).
I'd initate normal diagnostic measures
What's special about this machine compared to others that could interfear with normal function.
Can you replicate the target environment.
Is a stack trace available, does it contain any usefull values.
Can you deploy a version to the target that has additional value logging wrapped around the broken function (log all values before hitting the code that can cause the crash).
Visit the site with the target envirnment, and run the remote debugger from within their network.
Install Visual Studio (and all your source code) on that target machine and debug from there (kind of extreme).
I have found mdbg most helpful in these situations.
Just copy it to a flash disk.