Home Forums Discussions Problems Problem with black screen of death in 6.6.5

When viewing things in the imported files (like lab work) and discussing it with a patient, every so often a black screen of death appears as an insert and the AC program totally locks up. I am forced to restart the computer. Running 6.6.5, OptiPlex box (new) windows 7 professional over a Sonic and vpn. When I reboot the program I am unable to retrieve the chart and have to start the encounter over. Do you think this is a glitch in AC or a server/vpn/firewall issue....help. thanks everyone...

Can you explain more what you mean by over a Sonic and VPN?

Bert,

SonicWall is a popular small office firewall which does have VPN capabilities.

Todd,

If you are using Amazing Charts over a VPN, then the problems you speak of can very likely be caused by the slow performance of the VPN. Consider the following very possible scenario:

Many devices do not keep the VPN up all the time. During periods of inactivity, many devices will drop a VPN connection. This means that, when you request information from the remote host again, the devices responsible for the VPN have to renegotiate security, reestablish connections, and all that while the requesting application waits. The requesting application, in this case Amazing Charts, may "time-out" or "hang-up" with such a long unanticipated wait. Remember, AC has no idea you are using a VPN and that it should give things a few more seconds.

My recommendation is to do away with the VPN and use Amazing Charts over an RDP connection.

JamesNT

This is the screen that we see. The only solution is to restart the computer. We have installed an RDP connection and I will work with that today, but print functions on the RDP need refinement (I have printers in each exam room and currently the RDP connection doesn't have those listed). Thanks a always for all the help everyone.

Even if the VPN is point-to-point and always on, you are going to have latency issues with imported items as it is both I/O and transport intensive.

RDP should help, but the RDP client has to be configured to pass through printers and the drivers have to be matching. In the case of HP printers you often have to go to their universal print driver.

Todd, I know that you were a proponent of using folks who actually implement AC for large practices; I feel for you having to use the folks that the majority of the partners wanted - it sounds like it continues to be painful.

Here is a blog post explaining how to use RDP Easy Print which is built into Windows Server 2008 RDP and higher. No additional drivers are necessary.

http://blogs.msdn.com/b/rds/archive...dows-server-2008-r2.aspx?Redirected=true

JamesNT

I think he said a Dell OptiPlex.

James,

Thanks. I know what a Sonic firewall is. What I am confused about, is the setup. Is this being used in the cloud?

The only two cloud providers that host Amazing Charts that I am aware of are Amazing Charts itself, and Best For Your Practice (www.bestforyourpractice.com). Both use RDP, I don't think either one uses VPN.

JamesNT

But, except for stating it could be the Sonic or VPN, he hasn't said it is hosted. That is what I am getting at. There doesn't seem to be enough information to give a good, informed answer.

I had a similar problem, though I am in the cloud. Guardian angels told me there was an incompatibility with an older Adobe reader. They updated it and SO FAR things working ok. You might try updating your adobe to the latest.

Funny, Sandeep came up with a native version as well, but hey, whata does he know.

Sorry everyone...
Did not want to start controversy
My system is not hosted. All of the rooms are connected by a gigabit switch and that goes through the Sonic Wall with VPN over the net to my other office across town. I wish I was on the cloud, but was outvoted. You are all correct. A vpn is too slow and latency is causing AC to do strange things. I had a Corvette, no I have a YUGO...aka...Yugo away as I don't want to work now...LOL...thanks to all....the RDP is better, but again print controls need refinement and I am working on the above ideas....I will be in Chicago for the next meeting and will pick up the bar tab.

I didn't see any controversy at all. Glad it's working better. Are you using a terminal server?

todd,

Just for fun and for those not going to Chicago, would you be able to describe your exact topology? It seems you have one office with rooms connecting to a remote office, I assume with rooms. You are using a Sonic firewall and were using a vpn? Now you are using RDP. Exactly how? How is each computer at your remote office connecting to the database? Are you not using terminal services? Does each user have a TS license?

Jump

OK..hope I get this correct.

2 offices - main office houses AC with server. It has approx. 25-30 computers hooked to AC by a GIG switch. Computer response time at that office has been good. Occasional run time errors and pages freezing.

MY office is across town, we are a 2 doctor satellite office. A total of 20 computers hooked to AC through a gigabit switch, then a SONIC with a VPN. RECENTLY 2 of my rooms were converted to RDP with proper license and connect to the AC database across town, they appeared to be faster (approx. 15 percent) and Decision support structures and summary sections were slow but flawless - UNTIL today...when I got the black screen of death on a computer running through the RDP.

My partners are considering going back to 2 separate offices and 2 databases...I did not want to do that yet as I think this could work with the correct or improved configuration. Thanks to all...

Todd,

There is a problem with your network configuration to the remote office.

We have folks using our platform over RDP on DSL in a rural Alaska clinic that get better performance that you are getting.

While my guess is that the AC server in the main office probably could also use some tweaking (given the other errors), the network config is killing the remote office.

As has already been said, the local techs are apparently not up to the task, but your partners were warned of that and over-ruled your voice of reason.

Todd,

Your network at the main office that connect to a switch which connects them to a server. Well, OptiPlex. There is a database on the server. Each client computer connects to the database via the switch, but the user is using AC which is installed on their machine. They are NOT using AC on the server, e.g. all clients actually using the AC program on the server as that is not possible.

Now, one of your client computers should be a terminal server. It will have any application you wish to use such as Word, AC, whatever. It is connected to the database of the server. No one ever uses the terminal server. THE TERMINAL SERVER IS ONLY THERE FOR CONNECTIONS FROM YOUR REMOTE OFFICE. Any application on the TS can be used by as many users from your remote office as you'd like with the proper setup and licenses. You would remote using RDP which is VERY secure and very fast. Now, I say computers from your remote office, but it could be a smartphone, a tablet, a laptop in Japan. All users connect to the same app.

Thanks guys, I am in the midst of negotiations....I want to bring in "THE A TEAM"...to look over this configuration....and will bring hopefully a happy ending to this story....thanks again...and the bar bill could get huge with all of this help...we need to start a separate sheet on favorite watering holes so I can help with bar tabs...

Just to be clear, I am the thoughtful gray-haired one.

New ideas...
They say that 17 megs down and 2.5 megs up is not good enough to talk with the server across town. Want 5-10 megs upload speed at a cost of $$$.

And other costlier ideas were mentioned...the plot thickens...still with the black screen of death...amongst other quirks..

You probably need about 384 up and 384 down. That's the whole idea of RDP. You use hardly any bandwidth. You aren't sending any data over the Internet. You are using your keyboard and mouse to control the screen. Why would you need that much down and up?

Not saying I wouldn't get at least 1Mb down and up but only for using the Internet and downloading actual data.

Why not get the info from the guy who developed the remote desktop protocol from Microsoft.

http://blogs.msdn.com/b/rds/archive/2009/03/03/top-10-rdp-protocol-misconceptions-part-1.aspx

As he says, you can measure the bandwidth needed in Kbs. That's far from 17 Mbs. I think the A team may not be the right people to do this. Use Google yellow pages, find a company with MCITP and Microsoft MVP who specialize in networking. Generally, when these types of IT people do a job, they will get paid to look over your entire setup, sometimes with 10 to 30,000 dollar fluke meters to check every connection. But, it isn't the RDP that is causing the issue.

Once again, are you using a TS?

Can you let us know what is the deal and why they are recommending 2.5Mbps up?

Bert: Thanks for waiting as I had to gain some additional knowledge. The current IT people were not using a properly configured VPN/firewall set-up (my opinion and the opinion of a very good IT person well known to this board.) To overpower the problem the only solution from the current IT group was to try to increase upload speed.
Our company has decided to copy the database back to my site and re-install a server and go separate databases. I hope to be up and running soon. Sad I couldn't get the two offices to talk between computers in a faster way, but this is the best compromise. Thanks for all your help and insight.

I guess I don't understand why you can't simply put a terminal server in the host office, have no network in the other office and connect via RDP.

Pretty sure this has lots to do with egos, and not technology.

Having to bring in the right team to fix it would mean admitting they choose the wrong folks in the first place.

True, but you or I or Sandeep could walk him through a TS setup in an afternoon.

Although it would probably be a better walk with you or Sandeep, lol.

You are all correct. I know the terminal server system would work with the correct configuration, but alas you need to pick your battles so to speak....I am getting a more knowledgeable team and will be back up and running at proper efficiency soon. I have learned from this board and I thank you all. Indy has my confidence.

I should also point out (in fairness to him) that James may or may not be represented in that image.

A good TS would definitely work. I would suggest that you get the TS Setup ASAP rather than starting two separate databases. Merging them later will be a much more difficult and costly process. A simple way to test a TS solution would be to just set up RDP and see how it works. A VPN is never good for something that passes large amounts of data.

RDP was designed to run on dial up (56 kilobits/s compared to your 2.5 Megabits/s) That's like 45 times faster.

OK, I guess I will continue to try. I don't understand your company. Going to two databases is a huge step backwards. This really isn't that difficult.

Here is where I see the problem. From what you have stated, you have a total of 50 computers in two offices with the remote office running computers with AC on them and then trying to connect to the server over the Internet using a VPN. As Sandeep says, if a lot of data is going back and forth, it will be slow compared to using RDP.

I have eight computers and still find myself spending quite a bit of time maintaining the network. A 50 computer network for a doctor's office is definitely a SMB network. I would suggest getting rid of these "IT teams" such as the A-Team or any other one and hire one good half-time Microsoft-Certified Information Technology Professional. Doctors generally want to do things on the cheap, and it ends up costing them in the end. My network specialist always wonders why so many computer users, especially doctors, try to build and maintain their own network. Get one good IT person that will maintain your network and be available when you need them. A good MCITP or Network MVP probably would have had a TS set up by now. Likely your backups would be better. Your network would be more secure. I could go on and on.

I agree totally...I answered your pm...

Well, at least you provided a tech thread to keep me busy.