How to defeat the 'I don't know'

I'm going to assume it's your job to teach these people in some way: you are their lead, or a technical resource for them, and they are correctly coming to you for help with the immediate problem they face (my code no work, what this error, etc.)

You and the people have a model mismatch. They feel their problem is "I need to know what to change so this error message goes away" and you feel it is "I need to understand how to look up error messages so I can solve them myself" or "I need to see what misunderstanding of my language or other tool led to me writing something that produces this error message". If they shared your characterization of the problem, they would participate in the investigation you're trying to lead by asking and probing. The blankness and resistance is, as you already said, because "they're just focussed on solving the problem at hand."

What can you do about this? Probably the best thing is to surface it and talk about it. "Look, you can make the error message go away by just commenting out the line, but that's not the point, is it?" "That's happening because the file wasn't found, but let's drill into that a little and see why the file isn't there [or your code is using the wrong file name or whatever.]" Make a connection between the problem they're bringing you (even if you don't know the whole solution yet) and the questions you're asking them.

Compare:

"what is this message?" "Interesting, what is the xyz environment variable set to?" Total blank stare. Frustration for everyone.

"what is this message?" "That usually indicates a problem finding the config exceptions. Did you look at your environment variables, especially xyz? They control that." "No..." "Ok, let's check those right now."

The differences in the second one are many. You don't give an instant fix, you say "usually" and you're vague. That helps to combat "the expert knows what letters I need to press on the keyboard to make it all better" (think about that one git person who gives yo a string of commands you don't even try to understand). You give context and reason for your question. Your question doesn't assume they checked a thing, which might make them feel bad if they hadn't, but nor does it assume they haven't. It leads them through the process you would follow instead of asking for the result of a process they didn't know to follow. And then it offers to do the process together.

This is teaching. It's hard work. But if it's part of your job, do it. It's more rewarding than solving the immediate problem at hand over and over and never seeing people get better at what they're doing.

What you've described is not (in my book) a 'Software Engineer'.

The person you've described I would consider to be an 'Installation Technician' (no denigration intended.)

Have you considered changing the job title(s)?
Calling a VW a Ferrari won't make it win races...
The fictional romance of underdogs triumphing only occurs when the underdogs upskill (or in fiction.)

How do I give good guidance to help them overcome this attitude?

Make it clear (gently) that they are no longer in a classroom setting doing assignments as exercises that are meant to instruct and the outcome is already known. The time for training is over (except for adding-to and advancing the worker's facility at their craft.) They paid for education in the past; now they are being paid to use what they've learned -and can learn- to produce results. Merely 'installing' what they've found on the internet without deep comprehension of it or its applicability to fulfil requirements in this instance is not acceptable in the workforce.

It's harsh, but 'enabling' does not do any favour to those seeking the easiest way out of a situation.
Some things are difficult.
That's why the aptitude and attitude of an engineer is needed to fulfil the role of an engineer.

Seeking an analogy: Reading your question, and going back a few decades, it seems you are working with 'typists' and calling them 'secretaries'. Not disparaging the former, their function was to transcribe bodies of text. Expected of the latter would be, for instance, the abilities to correct spelling, punctuation & grammar, or to find and insert applicable reference 'links' only described by the author/boss.

Aside: There's a hilarious episode of HBO's "Silicon Valley" that includes a subplot centred on "The honey bear is sticky." It's important that one's assistants/co-workers are capable of making sense from ambiguity!

It may be possible to elevate your colleague's gaze to see that copy/paste without comprehension or analysis is not acceptable. Good luck, and I wish all of you success.

You cannot "defeat the 'I don't know'".
But, if you've the time, patience and skill, you may be able to stem the onslaught.

PS: Depending on your position in the company, you may want to consider that you are fulfilling your role, perhaps managing projects and people. You may no longer be down at the coalface simply writing code. Those days are likely behind you.

How do I give good guidance to help them overcome this attitude?

If you must give guidance, tell them to find another job!

Seriously, you can't teach curiosity or intellect.

If you have someone who is normally curious and intelligent who has turned and isn't progressing further, then it might just be a poor work environment.

But you'll also find people in life who are just not interested in being researchers or problem-solvers and never have been. They may be willing to learn and execute complex routines if you show them, but they won't perform the non-routine work and intelligent design typical of the capable developer.

The solution is to hold such developers to higher standards.

Whether you are the team lead or a peer, there should be some process for reviewing software designs and code. If there isn't, there should be, because that's a problem in itself. But either way, raise the standards for approving work in the review. Require them to demonstrate an understanding of their work beyond superficial Googling or generative AI'ing of a quick solution. If they don't , don't approve the review until they do.

Naturally, doing so is in tension with any pressure to produce quick results - but code that its own developer does not understand is a source of technical debt and future debugging, which will slow the development cycle all the more.

I ask them to clearly explain "A GOAL". Pick one, if there is more than one, and work it back to the begining.

Having multiple paths is encouraged.

From my experience, more often than not, the problem isn't lack of ability rather being overwhelmed.