Mar 30, 2016
Mar 7, 2016
Work Life - FIX: System Error detoured.dll is missing
I had a user that called with a problem logging into her computer. Upon boot, she was greeted with a dialog box that said "Logonui.exe cannot load. The program cannot start because detoured.dll is missing from your computer..."
After some extensive research and multiple dead ends, I found a solution that worked. I'm not if the solution breaks anything in the process, but I suppose time will tell there.
NOTE: The following info relates to your system registry. Modifying your registry can lead to negative results and may even make your system unusable. Use the following information AT YOUR OWN RISK. If you do not feel comfortable with the following, the DO NOT do them. I am NOT responsible for any negative effects changes to your registry may have on your system. The following is for information only.
Basically, this is what I did:
Note, the exact registry key info above came from:
http://www.megaleecher.net/One_Click_Solution_For_detoured.dll_Error#axzz42FLl8uGJ
After some extensive research and multiple dead ends, I found a solution that worked. I'm not if the solution breaks anything in the process, but I suppose time will tell there.
NOTE: The following info relates to your system registry. Modifying your registry can lead to negative results and may even make your system unusable. Use the following information AT YOUR OWN RISK. If you do not feel comfortable with the following, the DO NOT do them. I am NOT responsible for any negative effects changes to your registry may have on your system. The following is for information only.
Basically, this is what I did:
- Managed to get logged in by repeatedly clicking the OK button.
- The error resurfaced with ANY program I tried to run.
- I just kept clicking OK to get out of error and launch the program I wanted.
- Open REGEDIT as Administrator
- Navigate to the following key:
- HKEY_LOCAL_MACHINE\Software\Microsoft NT\CurrentVersion\Windows\
- On the right, I found the following entry:
- AppInit_DLLs
- I deleted the key (It had some kind of command in there I did not recognize, though it was NOT the detoured.dll, either. So... We'll see what adverse effects there are, if any, on the user's computer.
- Instantly, the errors disappeared. I could run any program (including the ones I had run before) without the error.
- Will scan the user's computer for malicious activity.
Note, the exact registry key info above came from:
http://www.megaleecher.net/One_Click_Solution_For_detoured.dll_Error#axzz42FLl8uGJ
Mar 4, 2016
Work Life - An Arkansas Panel Discussion About K12 Tech in Schools
Sharing a few thoughts on what I've seen/heard regarding the panel discussion at ARKSTE:
1) Sungard APIs might be available with v3.1 which will allow districts to use Sungard partners to connect to eSchool, providing "in and out" data movement. This seemed to be presented with mixed "openness" for districts. That is, certain panel members seemed much more restrictive to the concept than others. All-in-all, though, it is a step in the right direction.
2) SIF is dead in the water. Between the costs and the possibility of Sungard APIs, DIS sees no need for SIF.
3) We need more open channels and bridges of communication between DIS, ADE, and school districts regarding changes that affect school districts. Technology personnel MUST be made aware of changes that affect various systems in place - network, e-rate, funding, etc - long before those changes are presented to the legislature. We know the history of how that has played out in the past, so we can only wait and see if things will change in that regard. We, as technology folks, will have to keep with pending legislation and talk with our Supts and/or legislators as soon as we recognize a potential issue.
4) Act 1196 (Student Info Protection) could have a significant impact on #1 above. If we allow Act 1196 to be used as the scapegoat for preventing the use of Sungard-related APIs, then we will never see systems that allow us to exchange the information we need in order to provide the services we want/need to provide to our students, parents, etc. We will have to make sure that DIS, as the vendor, does not simply try to "hide" behind this Act as a way of preventing such services/access. I know the law is written such that we should be fine, but just be aware.
5) Any time we start talking "employment standards" for any position, but in our case for IT positions, you are treading on dangerous territory. We must be careful that setting a standard does not backfire on us. Many of us are not tech certified yet could run circles in an educational environment around those who are certified. If we are working to establish "devices-per-tech" standards, we must also be careful there. Ultimately, any standards could serve to provide a district with a reason to outsource the IT department. So, before you fight for certain standards, think about how those standards could have adverse effects and then figure out how to address those in your proposals/presentations, especially when it comes to smaller and/or poorer districts.
6) ADE is a customer of DIS. Every agency pays DIS for services. This is exactly as I have been saying - DIS is a vendor. There are specifications and requirements that go along with that partnership. Some of that comes by way of testing new systems, handling hack attacks, etc. By the same token, DIS must be held to the same standards as any vendor with which we work. "DIS is never going to recommend that we be on the cutting edge of any new software...", Mark Myers, DIS. Software used by the state is customized, but that has been reduced over the years because the changing nature of the products offered. Customization, according to Myers, in many cases comes because certain features are not available in the version of software being used.
7) "Java (garbled) is actually a security enhancement," Mark Myers, DIS. I'm not even touching this one. Fellow techs may feel free to chime in as they see fit.
Feb 27, 2016
Feb 23, 2016
Work Life: Two ports in the sea
An area school reached out because they were having some very bizarre network issues. They had replaced several switches on their network and things seemed to be going fine - for a while. Soon, they noticed segments of the network were crashing or coming to a grinding slowdown. First inclination is to blame and look for a network loop in effect.
For those that may not know, a network loop happens when you take a network cable and plug both ends into the same switch. For example, you plug one end into port 1 and the other into port 8 on the same switch. Much like an echo between speakers and a microphone, the network traffic coming out of one end feeds into the other end, which then feeds it back to the first end. Lather, rinse, repeat. With microphones and speakers, we hear the loud squeal of feedback. On a network, traffic loops in an ever-increasing roundabout fashion, bringing things to a standstill.
The same thing (or similar, anyway) can happen if two network wires from one switch are plugged into two ports on another switch. For example, Port 3 and 4 on one switch are plugged into ports 1 and 4 on another switch (the actual port number do not matter). This is usually called "spanning tree" since it is between two switches, though the term can also be used within a single switch.*
So, you with me? Okay, here's the situation then:
When the tech plugged in a new switch via fiber, the network would come crashing down. Okay, we thought, must be a loop somewhere in the "new" network since things worked fine before hooking up the new switch. Except for one problem: it happened even when the new switch had NO OTHER connections attached - just the fiber from the main network switch. Unplug the fiber, and the network settled back to normal.
Okay, let's see what else we have then. We head to the main network switch (also referred to as the core switch) to see what we can figure out. As we looked over things, I had to climb a ladder in order to get to the core switch because it was mounted high in the network closet's rack.
After a few moments, I realized the problem: they didn't have a loop so much as they had two network lines plugged into the same port. Wait. What? How could they have two wires in the same port? Allow me to demonstrate. Note: The image below is NOT the actual switch in this post. I recreated the scenario using my own switch.
Now, you may be saying, "Those circled wires are not in the same port!" While that is true, physically, it is not true logically. Notice on the left, the port number is 23. On the right, it is also 23. In most switches that have CAT5 (left) and fiber (right), they share certain ports. In the image above, ports 21-24 are "shared." This means you can EITHER have a CAT5 wire in a port number *OR* you can fiber in the port number. At least, from a logical sense. In a physical sense, you can plainly see there is nothing stopping me from plugging a wire into both ports. The switch in this case sees both as perfectly legitimate and sends/receives traffic down BOTH of the Number 23 ports. Much like a network loop, traffic spins out of control as the switch sends and receives data down both paths.
That is what happened at the district. Now, seeing the example above makes it look like the problem is obvious, right? Well, in the example above, it is obvious. In the real world scenario, as I mentioned before, the switch was mounted up high. Additionally, that switch had the port numbers on the TOP of the ports, not the bottom. So, the tech could not see that the fiber ports were shared with ports 23 and 24 (that switch only had two fiber ports).
Because the tech could not see the numbers, the fiber was plugged into Port 24. There was also a CAT5 wire plugged into Port 24. So long as the fiber was not plugged in on the other end, everything was fine. As soon as the fiber made the connection in the other switch, everything went crazy, as by now you might imagine.
The moral of the story here is that we can't always tell the exact nature of the problem due to the actual physical parameters of the environment. In this case, the tech could not see the numbers on the ports, thus not realize wires had been plugged into the shared ports on the switch.
Sometimes, it truly does take a different set of eyes to help solve a problem.
*Note: Some switches can be configured to handle such arrangements. This can take the shape of VLANS (virtual local area networks) or spanning tree detection/prevention. You may have heard these referred to as Layer 2 or Layer 3 switches.
For those that may not know, a network loop happens when you take a network cable and plug both ends into the same switch. For example, you plug one end into port 1 and the other into port 8 on the same switch. Much like an echo between speakers and a microphone, the network traffic coming out of one end feeds into the other end, which then feeds it back to the first end. Lather, rinse, repeat. With microphones and speakers, we hear the loud squeal of feedback. On a network, traffic loops in an ever-increasing roundabout fashion, bringing things to a standstill.
The same thing (or similar, anyway) can happen if two network wires from one switch are plugged into two ports on another switch. For example, Port 3 and 4 on one switch are plugged into ports 1 and 4 on another switch (the actual port number do not matter). This is usually called "spanning tree" since it is between two switches, though the term can also be used within a single switch.*
So, you with me? Okay, here's the situation then:
When the tech plugged in a new switch via fiber, the network would come crashing down. Okay, we thought, must be a loop somewhere in the "new" network since things worked fine before hooking up the new switch. Except for one problem: it happened even when the new switch had NO OTHER connections attached - just the fiber from the main network switch. Unplug the fiber, and the network settled back to normal.
Okay, let's see what else we have then. We head to the main network switch (also referred to as the core switch) to see what we can figure out. As we looked over things, I had to climb a ladder in order to get to the core switch because it was mounted high in the network closet's rack.
After a few moments, I realized the problem: they didn't have a loop so much as they had two network lines plugged into the same port. Wait. What? How could they have two wires in the same port? Allow me to demonstrate. Note: The image below is NOT the actual switch in this post. I recreated the scenario using my own switch.
Now, you may be saying, "Those circled wires are not in the same port!" While that is true, physically, it is not true logically. Notice on the left, the port number is 23. On the right, it is also 23. In most switches that have CAT5 (left) and fiber (right), they share certain ports. In the image above, ports 21-24 are "shared." This means you can EITHER have a CAT5 wire in a port number *OR* you can fiber in the port number. At least, from a logical sense. In a physical sense, you can plainly see there is nothing stopping me from plugging a wire into both ports. The switch in this case sees both as perfectly legitimate and sends/receives traffic down BOTH of the Number 23 ports. Much like a network loop, traffic spins out of control as the switch sends and receives data down both paths.
That is what happened at the district. Now, seeing the example above makes it look like the problem is obvious, right? Well, in the example above, it is obvious. In the real world scenario, as I mentioned before, the switch was mounted up high. Additionally, that switch had the port numbers on the TOP of the ports, not the bottom. So, the tech could not see that the fiber ports were shared with ports 23 and 24 (that switch only had two fiber ports).
Because the tech could not see the numbers, the fiber was plugged into Port 24. There was also a CAT5 wire plugged into Port 24. So long as the fiber was not plugged in on the other end, everything was fine. As soon as the fiber made the connection in the other switch, everything went crazy, as by now you might imagine.
The moral of the story here is that we can't always tell the exact nature of the problem due to the actual physical parameters of the environment. In this case, the tech could not see the numbers on the ports, thus not realize wires had been plugged into the shared ports on the switch.
Sometimes, it truly does take a different set of eyes to help solve a problem.
*Note: Some switches can be configured to handle such arrangements. This can take the shape of VLANS (virtual local area networks) or spanning tree detection/prevention. You may have heard these referred to as Layer 2 or Layer 3 switches.
Subscribe to:
Posts (Atom)